SIP ALG

SIP ALG-Betrieb

Es gibt zwei Arten von SIP-Datenverkehr, die Signalübertragung und den Medienstrom. Der SIP-Signalverkehr besteht aus Anforderungs- und Antwortmeldungen zwischen Client und Server und verwendet Transportprotokolle wie UDP oder TCP. Der Medien-Stream transportiert die Daten (z. B. Audiodaten) mithilfe von Transportprotokollen.

Ab Junos OS Version 12.3X48-D25 und Junos OS Version 17.3R1 unterstützt das SIP ALG TCP. Die TCP-Unterstützung über das SIP ALG reduziert den Datenverkehr zum Server, da keine erneute Registrierung oder aktualisierung des Servers erforderlich ist.

Standardmäßig unterstützt Junos OS SIP-Signalmeldungen am Port 5060. Sie können den Port konfigurieren, indem Sie eine Richtlinie erstellen, die einen SIP-Service zulässt, und die Software filtert SIP-Signalübertragungsverkehr wie jede andere Art von Datenverkehr, was dies zulässt oder verweigert. Der Medienstrom verwendet jedoch dynamisch zugewiesene Portnummern, die sich während eines Anrufs mehrmals ändern können. Ohne feste Ports ist es unsicher, eine statische Richtlinie zur Steuerung des Mediendatenverkehrs zu erstellen. In diesem Fall ruft das Gerät das SIP ALG auf. Die für die Mediensitzungen verwendeten Geräteübertragungsports sind im Voraus nicht bekannt; Die für die SIP-Aushandlung verwendeten Ports sind jedoch bekannt (oder vordefinierte). Das ALG registriert Interesse an Paketen von der Steuerungssitzung, die es leicht von den anderen Paketen unterscheiden kann, und prüft die Aushandlung der Transportinformationen, die für die Mediensitzung verwendet werden (sowohl IP-Adressen als auch Ports).

Das SIP ALG überwacht SIP-Transaktionen und erstellt und verwaltet pinholes dynamisch basierend auf den Informationen, die es aus diesen Transaktionen extrahiert. Das Juniper Networks SIP ALG unterstützt alle SIP-Methoden und -Antworten. Sie können SIP-Transaktionen durch die Firewall von Juniper Networks durchqueren, indem Sie eine statische Richtlinie erstellen, die den SIP-Service zulässt. Wenn die Richtlinie so konfiguriert ist, dass der SIP-Datenverkehr untersucht wird (oder wenn die Richtlinie einen Teil des Datenverkehrs zur Überprüfung an das SIP ALG sendet), sind die zulässigen Aktionen, den Datenverkehr zu erlauben (in diesem Fall werden die entsprechenden Pinholes geöffnet) oder den Datenverkehr zu verweigern.

Das SIP ALG fängt SIP-Nachrichten ab, die SDP enthalten, und extrahiert mithilfe eines Parsers die Informationen, die zum Erstellen von Pinholes erforderlich sind. Das SIP ALG untersucht den SDP-Teil des Pakets, und ein Parser extrahiert Informationen wie IP-Adressen und Portnummern, die das SIP ALG in einer Pinhole-Tabelle aufzeichnet. Das SIP ALG nutzt die in der Pinhole-Tabelle aufgezeichneten IP-Adressen und Portnummern, um Pinholes zu öffnen und Medienströme durch das Gerät zu ermöglichen.

NEC SIP-Produkte werden bedingt unterstützt.

SDP-Sitzungsbeschreibungen

Eine SDP-Sitzungsbeschreibung ist ein klar definiertes Format für die Übermittlung ausreichender Informationen, um eine Multimedia-Sitzung zu entdecken und an dieser teilzunehmen. Eine Sitzung wird von einer Reihe von Attribut-/Wertpaaren pro Zeile beschrieben. Die Attributnamen sind einzelne Zeichen, gefolgt von =, und ein Wert. Optionale Werte werden mit =* angegeben. Werte sind entweder eine ASCII-Zeichenfolge oder eine Sequenz bestimmter Typen, die durch Leerzeichen getrennt sind. Attributnamen sind nur innerhalb des zugeordneten syntaktischen Konstrukts eindeutig, z. B. nur innerhalb der Sitzung, Zeit oder medien.

Von den vielen Feldern in der SDP-Beschreibung sind zwei besonders für das SIP ALG nützlich, da sie Transportschichtinformationen enthalten.

• c= für Verbindungsinformationen

  Dieses Feld kann auf Sitzungs- oder Medienebene angezeigt werden. Es erscheint in diesem Format:

  c=<Netzwerktyp><Addresstyp><verbindungsadresse>

  Junos OS unterstützt nur "IN" (für Internet) als Netzwerktyp, "IPv4" als Adresstyp und eine Unicast-IP-Adresse oder einen Domänennamen als Ziel (Verbindung) IP-Adresse. Ab Junos OS Version 15.1X49-D40 und Junos OS Version 17.3R1 wird auch der Adresstyp "IPv6" unterstützt.

  Wenn es sich bei der Ziel-IP-Adresse um eine Unicast-IP-Adresse handelt, erstellt das SIP ALG Pinholes unter Verwendung der ip-Adresse und Portnummern, die im Medienbeschreibungsfeld m= angegeben sind.

• m= für Die Medienmitteilung

  Dieses Feld wird auf Medienebene angezeigt und enthält die Beschreibung der Medien. Es erscheint in diesem Format:

  m=<media><port><transport><fmt-Liste>

  Derzeit unterstützt Junos OS "RTP" als Transportprotokoll auf Anwendungsebene. Die Portnummer gibt den Zielport des Medienstreams an (der Ursprung wird von der Remote-UA zugewiesen). Die Formatliste (FMT-Liste) enthält Informationen zum Anwendungsschichtprotokoll, das von den Medien verwendet wird.

  Die Software öffnet Ports nur für RTP und Real-Time Control Protocol (RTCP). Jede RTP-Sitzung verfügt über eine entsprechende RTCP-Sitzung. Wenn ein Medien-Stream RTP verwendet, muss das SIP ALG daher Ports für RTP- und RTCP-Datenverkehr reservieren (Pinholes erstellen). Standardmäßig ist die Portnummer für RTCP eine höher als die RTP-Portnummer.

Pinhole-Erstellung

Jedes Pinhole (eines für RTP-Datenverkehr und das andere für RTCP-Datenverkehr) teilen sich dieselbe Ziel-IP-Adresse. Die IP-Adresse stammt aus dem Feld c= in der Beschreibung der SDP-Sitzung. Da das Feld c= entweder auf Sitzungsebene oder im Teil der SDP-Sitzungsbeschreibung auf Medienebene angezeigt werden kann, ermittelt der Parser die IP-Adresse anhand der folgenden Regeln (gemäß SDP-Konventionen):

• Zunächst sucht der SIP ALG-Parser nach einem c=-Feld, das eine IP-Adresse auf Medienebene enthält. Wenn es ein solches Feld gibt, extrahiert der Parser diese IP-Adresse, und das SIP ALG verwendet diese Adresse, um ein Pinhole für die Medien zu erstellen.

• Wenn auf Medienebene kein c=-Feld vorhanden ist, extrahiert der SIP ALG-Parser die IP-Adresse aus dem Feld c= auf Sitzungsebene, und das SIP ALG verwendet diese IP-Adresse, um ein Pinhole für die Medien zu erstellen. Wenn die Sitzungsbeschreibung in beiden Ebenen kein Feld c= enthält, zeigt dies einen Fehler im Protokollstapel an, und das Gerät löscht das Paket und protokolliert das Ereignis.

Das SIP ALG öffnet auch Pinholes für den Signalverkehr. Diese Signal-Pinholes sind nach dem Timeout der vorherigen Signalsitzung nützlich, und sie sind auch für den Signaldatenverkehr nützlich, der an eine Drittanbieteradresse gesendet wird, die nicht mit der vorherigen Signalsitzung übereinstimmt. Im Gegensatz zu RTP- oder RTCP-Pinholes, bei denen nur die Ziel-IP und der Ziel-Port angegeben sind, werden die SIP ALG-Signal-Pinholes nie ausge altert.

Das SIP ALG öffnet bei Bedarf Signal-Pinholes für folgende Header:

• Über

• KONTAKT

• ROUTE

• REKORD-ROUTE

Das SIP ALG benötigt die folgenden Informationen, um ein Pinhole zu erstellen. Diese Informationen stammen entweder aus der Beschreibung der SDP-Sitzung oder aus den SIP-Headern (wie oben aufgeführt).

• Protokoll – UDP oder TCP.

• Quell-IP – Unbekannt.

• Quell-Port – Unbekannt.

• Ziel-IP: Der Parser extrahiert die Ziel-IP-Adresse aus dem Feld c= auf Medien- oder Sitzungsebene.

• Zielport: Der Parser extrahiert die Zielportnummer für RTP aus dem Feld m= auf Medienebene und berechnet die Zielportnummer für RTCP mit der folgenden Formel:

  RTP-Portnummer + 1

• Lebensdauer : Dieser Wert gibt die Dauer der Zeit (in Sekunden) an, während der ein Pinhole geöffnet ist, um ein Paket durchzulassen. Ein Paket muss das Pinhole durchlaufen, bevor die Lebensdauer abläuft. Wenn die Lebensdauer abläuft, entfernt das SIP ALG das Pinhole.

  Wenn ein Paket innerhalb der Lebensdauer durch das Pinhole geht, entfernt das SIP ALG unmittelbar danach das Pinhole für die Richtung, aus der das Paket kam.

  Abbildung 1 beschreibt eine Anrufeinrichtung zwischen zwei SIP-Clients und wie das SIP ALG Pinholes erstellt, um RTP- und RTCP-Datenverkehr zu ermöglichen. Die Abbildung setzt voraus, dass das Gerät über eine Richtlinie verfügt, die SIP zulässt, und öffnet somit Port 5060 für SIP-Signalmeldungen.

  Abbildung 1: SIP-ALG-Anrufeinrichtung

• Verstehen der IPv6-Unterstützung für SIP ALG
• Verstehen der Skalierung von Busy Lamp Field Support für das UDP-basierte SIP-ALG
• Understanding SIP ALG Request Methods
• SIP ALG – Konfigurationsübersicht
• Verstehen von SIP ALG DoS-Angriffsschutz
• Understanding SIP ALG Unknown Message Types
• Verstehen der Dauer und Timeouts von SIP ALG-Anrufen

Beibehalten von SIP ALG Hold Resources (CLI-Verfahren)

Um die proprietären SIP-Anrufströme zu berücksichtigen:

Ausgehende Anrufe

Wenn ein SIP-Anruf mit einer SIP-Anfragenachricht vom internen zum externen Netzwerk eingeleitet wird, ersetzt NAT die IP-Adressen und Portnummern in der SDP und bindet die IP-Adressen und Portnummern an die Firewall von Juniper Networks. Via-, Contact-, Route- und Record-Route SIP-Header-Felder sind, falls vorhanden, auch an die Firewall-IP-Adresse gebunden. Das ALG speichert diese Zuordnungen für die Verwendung in Retransmissionen und für SIP-Antwortnachrichten.

Das SIP ALG öffnet dann Pinholes in der Firewall, um Medien über das Gerät auf den dynamisch zugewiesenen Ports zu ermöglichen, die basierend auf Informationen in den SDP- und den Via-, Contact- und Record-Route-Headerfeldern ausgehandelt werden. Die Pinholes ermöglichen es auch eingehenden Paketen, die Kontakt-, Via- und Record-Route-IP-Adressen und -Ports zu erreichen. Bei der Verarbeitung des Rückverkehrs fügt das ALG die ursprünglichen SIP-Felder Contact, Via, Route und Record-Route wieder in Pakete ein.

Eingehende Anrufe

Eingehende Anrufe werden vom öffentlichen Netzwerk zu öffentlichen statischen NAT-Adressen oder zur Schnittstelle von IP-Adressen auf dem Gerät eingeleitet. Statische NATs sind statisch konfigurierte IP-Adressen, die auf interne Hosts verweisen; Schnittstellen-IP-Adressen werden vom ALG dynamisch aufgezeichnet, da es REGISTER-Nachrichten überwacht, die von internen Hosts an den SIP-Registrar gesendet werden. Wenn das Gerät ein eingehendes SIP-Paket empfängt, richtet es eine Sitzung ein und leitet die Payload des Pakets an das SIP ALG weiter.

Das ALG prüft die SIP-Anfragenachricht (zunächst eine EINLADUNG) und öffnet auf Der Grundlage der SDP-Informationen Tore für ausgehende Medien. Wenn eine 200-OK-Antwortnachricht eintrifft, führt das SIP ALG NAT an den IP-Adressen und Ports aus und öffnet Pinholes in Ausgehende Richtung. (Die geöffneten Tore haben eine kurze Time-to-Live und sie haben eine Auszeit, wenn eine 200 OK-Antwortnachricht nicht schnell empfangen wird.)

Wenn eine Antwort mit 200 OK eintrifft, überprüft der SIP-Proxy die SDP-Informationen und liest die IP-Adressen und Portnummern für jede Mediensitzung. Das SIP-ALG auf dem Gerät führt NAT an den Adressen und Portnummern aus, öffnet Pinholes für ausgehenden Datenverkehr und aktualisiert das Timeout für Gates inbound-Richtung.

Wenn der ACK für die 200 OK ankommt, passiert er auch das SIP ALG. Wenn die Nachricht SDP-Informationen enthält, stellt das SIP ALG sicher, dass die IP-Adressen und Portnummern nicht von der vorherigen EINLADUNG geändert werden. Wenn dies der Grund dafür ist, löscht das ALG alte Pinholes und erstellt neue Pinholes, damit Medien passieren können. Das ALG überwacht auch die SIP-Felder Via, Contact und Record-Route und öffnet neue Pinholes, wenn festgestellt wird, dass sich diese Felder geändert haben.

Weitergeleitete Anrufe

Ein weitergeleiteter Anruf ist beispielsweise dann, wenn Benutzer A außerhalb des Netzwerks Benutzer B im Netzwerk anruft und Benutzer B den Anruf an Benutzer C außerhalb des Netzwerks weiterleitet. Das SIP ALG verarbeitet die EINLADUNG von Benutzer A als normalen eingehenden Anruf. Wenn das ALG jedoch den weitergeleiteten Anruf von B nach C außerhalb des Netzwerks untersucht und feststellt, dass B und C über dieselbe Schnittstelle erreicht werden, werden keine Pinholes in der Firewall geöffnet, da die Medien direkt zwischen Benutzer A und Benutzer C fließen.

Anrufbeendigung

Die BYE-Nachricht beendet einen Anruf. Wenn das Gerät eine BYE-Nachricht empfängt, übersetzt es die Header-Felder genauso wie jede andere Nachricht. Da jedoch eine BYE-Nachricht vom Empfänger mit einem 200 OK erkannt werden muss, verzögert die ALG das Abreißen des Anrufs um 5 Sekunden, um die Übertragung des 200 OK zu ermöglichen.

Nachrichten zur erneuten Einladung von Anrufen

Re-INVITE-Nachrichten fügen einem Anruf neue Mediensitzungen hinzu und entfernen vorhandene Mediensitzungen. Wenn einem Anruf neue Mediensitzungen hinzugefügt werden, werden neue Pinholes in der Firewall geöffnet und neue Adressbindungen erstellt. Der Vorgang ist identisch mit der ursprünglichen Anrufeinrichtung. Wenn alle Mediensitzungen oder Medien-Pinholes aus einem Anruf entfernt werden, wird der Anruf entfernt, wenn eine BYE-Nachricht empfangen wird.

Anrufsitzungs-Timer

Als Vorsichtsmaßnahme verwendet das SIP ALG harte Timeout-Werte, um die maximale Zeit festzulegen, für die ein Anruf vorhanden sein kann. Auf diese Weise wird sichergestellt, dass das Gerät geschützt ist, sollte eines der folgenden Ereignisse auftreten:

• Endsysteme stürzen während eines Anrufs ab, und eine BYE-Nachricht wird nicht empfangen.

• Böswillige Benutzer senden niemals ein BYE, um ein SIP-ALG anzugreifen.

• Unzureichende Implementierungen von SIP-Proxy verarbeiten Record-Route nicht und senden niemals eine BYE-Nachricht.

• Netzwerkausfälle verhindern, dass eine BYE-Nachricht empfangen wird.

Stornierung von Anrufen

Jede Partei kann einen Anruf abbrechen, indem sie eine CANCEL-Nachricht sendet. Nach Empfang einer CANCEL-Nachricht schließt das SIP ALG die Pinholes durch die Firewall – falls vorhanden – und veröffentlicht Adressbindungen. Bevor die Ressourcen freigegeben werden, verzögert die ALG das Age-out des Kontrollkanals um etwa 5 Sekunden, um die Zeit für das endgültige 200 OK zu ermöglichen. Der Anruf wird beendet, wenn das 5-Sekunden-Timeout abläuft, unabhängig davon, ob eine 487- oder nicht-200-Antwort eintrifft.

Gabelung

Forking ermöglicht es einem SIP-Proxy, eine einzelne INVITE-Nachricht gleichzeitig an mehrere Ziele zu senden. Wenn die mehreren 200 OK-Antwortmeldungen für den einzelnen Anruf eintreffen, analysiert das SIP ALG die Anrufinformationen mit den ersten 200 OK-Nachrichten, die es empfängt, aber aktualisiert.

SIP-Nachrichten

Das SIP-Nachrichtenformat besteht aus einem SIP-Header-Abschnitt und dem SIP-Text. In Anforderungsmeldungen ist die erste Zeile des Header-Abschnitts die Anforderungszeile, die den Methodentyp, request-URI und die Protokollversion umfasst. In Antwortmeldungen ist die erste Zeile die Statuszeile, die einen Statuscode enthält. SIP-Header enthalten IP-Adressen und Portnummern, die für die Signalübertragung verwendet werden. Der SIP-Text, der durch eine Leere vom Header-Abschnitt getrennt ist, ist für Informationen zur Sitzungsbeschreibung reserviert, was optional ist. Junos OS unterstützt derzeit nur SDP. Der SIP-Text enthält IP-Adressen und Portnummern, die für die Übertragung der Medien verwendet werden.

SIP-Header

In der folgenden SIP-Anfrage-Beispielnachricht ersetzt NAT die IP-Adressen in den Header-Feldern, um sie außerhalb des Netzwerks zu verbergen.

Wie die IP-Adressenübersetzung durchgeführt wird, hängt vom Typ und der Richtung der Nachricht ab. Eine Nachricht kann eine der folgenden Sein:

• Eingehende Anfrage

• Ausgehende Reaktion

• Ausgehende Anfrage

• Eingehende Reaktion

Tabelle 1 zeigt, wie in jedem dieser Fälle NAT durchgeführt wird. Beachten Sie, dass die ALG bei mehreren Headerfeldern mehr als nur bestimmt, ob die Nachrichten von innen oder außerhalb des Netzwerks kommen. Er muss auch bestimmen, welcher Client den Anruf initiiert hat und ob es sich bei der Nachricht um eine Anfrage oder Antwort handelt.

SIP-Text

Die SDP-Informationen im SIP-Text enthalten IP-Adressen, die das ALG zum Erstellen von Kanälen für den Medienstream verwendet. Die Übersetzung des SDP-Abschnitts weist auch Ressourcen zu, d. h. Portnummern, die gesendet und empfangen werden sollen.

Der folgende Auszug aus einem Beispiel-SDP-Abschnitt zeigt die Felder, die für die Ressourcenzuweisung übersetzt werden.

SIP-Nachrichten können mehr als einen Medien-Stream enthalten. Das Konzept ähnelt dem Anhängen mehrerer Dateien an eine E-Mail-Nachricht. Beispielsweise kann eine EINLADUNGsnachricht, die von einem SIP-Client an einen SIP-Server gesendet wird, folgende Felder aufweisen:

Junos OS unterstützt bis zu 6 für jede Richtung ausgehandelte SDP-Kanäle für insgesamt 12 Kanäle pro Anruf. Weitere Informationen finden Sie unter Understanding the SIP ALG.

SIP-NAT-Szenario

Abbildung 2 und Abbildung 3 zeigen einen SIP-Anruf INVITE und 200 OK. In Abbildung 2 sendet ph1 eine SIP-EINLADUNGsnachricht an ph2. Beachten Sie, wie die IP-Adressen in den Kopfzeilenfeldern , die in fetter Schrift angezeigt werden, vom Gerät übersetzt werden.

Der SDP-Abschnitt der INVITE-Nachricht gibt an, wo der Anrufer bereit ist, Medien zu erhalten. Beachten Sie, dass das Media Pinhole für RTCP und RTP zwei Portnummern enthält, 52002 und 52003. Das Via/Contact Pinhole gibt die Portnummer 5060 für DIE SIP-Signalübertragung an.

Beobachten Sie, wie in der Antwortnachricht 200 OK in Abbildung 3 die in der INVITE-Nachricht durchgeführten Übersetzungen umgekehrt werden. Die in dieser Nachricht aufgeführten IP-Adressen werden nicht übersetzt, aber Die Tore werden geöffnet, um den Zugriff auf das private Netzwerk über medienstromgebundene Medien zu ermöglichen.

Abbildung 2: SIP-NAT-Szenario 1

Abbildung 3: SIP-NAT-Szenario 2

Kurse von SIP-Antworten

SIP-Antworten liefern Statusinformationen zu SIP-Transaktionen und enthalten einen Antwortcode und einen Grundbegriff. SIP-Antworten werden in die folgenden Klassen gruppiert:

• Informational (100 bis 199) – Anfrage eingegangen, weiter bearbeiten.

• Erfolg (200 bis 299) – Aktion wurde erfolgreich empfangen, verstanden und akzeptiert.

• Umleitung (300 auf 399): Weitere Maßnahmen, die zum Ausfüllen der Anfrage erforderlich sind.

• Clientfehler (400 bis 499): Die Anfrage enthält eine schlechte Syntax oder kann auf diesem Server nicht erfüllt werden.

• Serverfehler (500 bis 599): Server konnte eine offenbar gültige Anfrage nicht erfüllen.

• Globaler Fehler (600 bis 699): Die Anfrage kann auf keinem Server erfüllt werden.

Tabelle 2 enthält eine vollständige Liste der aktuellen SIP-Antworten.

NAT-Modus im reinen IPv6-Modus (NAT66) für SIP IPv6 ALG

Das SIP IPv6 ALG unterstützt NAT66 genau wie NAT44. NAT66 (IPv6 NAT) bietet Quell-NAT und statische NAT-Funktionen ähnlich NAT44 (IPv4 NAT).

NAT-PT

Network Address Translation Protocol Translation (NAT-PT) (RFC 2766) ist ein Protokollübersetzungsmechanismus, der die Kommunikation zwischen nur IPv6- und IPv4-Knoten über eine protokollunabhängige Übersetzung von IPv4- und IPv6-Datagrammen ermöglicht. Für die Sitzung sind keine Statusinformationen erforderlich.

NAT-PT wird durch normale NAT implementiert, von IPv6-Adresse zu IPv4-Adresse und umgekehrt. Das SIP ALG verarbeitet diese Adressübersetzungen im Payload genauso, wie die Adressen in normaler NAT verarbeitet werden.

NAT-PT bindet die Adressen im IPv6-Netzwerk an Adressen im IPv4-Netzwerk und umgekehrt, um ein transparentes Routing für die Datagramme bereitzustellen, die zwischen Adressbereichen übertragen werden.

Der Hauptvorteil von NAT-PT besteht darin, dass die Endgeräte und Netzwerke entweder IPv4-Adressen oder IPv6-Adressen ausführen können und der Datenverkehr von jeder Seite gestartet werden kann.

NAT64

NAT64 ist ein Mechanismus, mit dem IPv6-Hosts mit IPv4-Servern kommunizieren können. NAT64 ist erforderlich, um die Zuordnung von IPv6- zu IPv4-Adressen zu behalten. Eine solche Adresszuordnung wird entweder statisch vom Systemadministrator konfiguriert (zustandslose Übersetzung) oder häufiger automatisch erstellt, wenn das erste Paket aus dem IPv6-Netzwerk NAT64 erreicht, das übersetzt werden soll (stateful).

NAT64 wird auf Geräten mit persistenter NAT implementiert. Wenn die erste SIP-Anfragenachricht (das erste Paket sollte nur aus IPv6 stammen) das DUT quer durchgeht, wird die Adressbindung erstellt und dann können die Pakete in beide Richtungen fließen.

Der NAT64-Mechanismus übersetzt IPv6-Pakete in IPv4-Pakete und umgekehrt, wodurch IPv6-Clients mithilfe von Unicast UDP, TCP oder ICMP Kontakt zu den IPv4-Servern aufnehmen können. Das NAT-PT- und NAT64-Verhalten scheint ähnlich zu sein, aber diese Mechanismen werden unterschiedlich implementiert.

Wenn NAT64 mit persistenter NAT implementiert ist, fügt SIP ALG mit IPv6-Unterstützung die NAT-Übersetzung zur persistenten NAT-Bindungstabelle hinzu, wenn NAT auf der Adressenadresse des Datensatzes konfiguriert ist. Da persistente NAT die konfigurierte Adresse nicht duplizieren kann, wird die Koexistenz von NAT66- und NAT64-Konfigurationen auf der gleichen Adresse nicht unterstützt.

Für dieselbe Quell-IP-Adresse wird nur eine Bindung erstellt.

STUN und SIP ALG

Session Traversal Utilities für NAT (STUN) ist eine Lösung, mit der VoIP über NAT und Firewall funktionieren kann.

Zuvor hatte STUN ohne SIP ALG gearbeitet. Dies bedeutet, dass das SIP ALG nicht beteiligt war, wenn persistente NAT konfiguriert wurde.

STUN kann mit dem SIP ALG koexistieren und SIP ALG ist beteiligt, wenn persistente NAT konfiguriert wird.

Verstehen des eingehenden SIP ALG-Anrufsupports mit dem SIP-Registrar und NAT

Die Session Initiation Protocol (SIP)-Registrierung bietet eine Erkennungsfunktion, anhand derer SIP-Proxys und Standortserver den Standort oder die Standorte identifizieren können, an denen Benutzer kontaktiert werden möchten. Ein Benutzer registriert einen oder mehrere Kontaktorte, indem er eine REGISTER-Nachricht an den Registrar sendet. Die To- und Contact-Felder in der REGISTER-Nachricht enthalten den Uniform Resource Identifier (URI) und mindestens eine Kontakt-URIs (siehe Abbildung 4). Die Registrierung erstellt Bindungen in einem Standortdienst, der die Adressdaten mit der Kontaktadresse oder den Adressen verknüpft.

Das Gerät überwacht ausgehende REGISTER-Nachrichten, führt Network Address Translation (NAT) auf diesen Adressen aus und speichert die Informationen in einer eingehenden NAT-Tabelle. Wenn dann eine INVITE-Nachricht von außerhalb des Netzwerks empfangen wird, verwendet das Gerät die eingehende NAT-Tabelle, um zu ermitteln, an welchen internen Host die INVITE-Nachricht weitergeleitet werden soll. Sie können den SIP-Proxyregistrierungsdienst nutzen, um eingehende Anrufe zu ermöglichen, indem Sie Schnittstellenquellen-NAT oder NAT-Pools auf der Ausgangsschnittstelle des Geräts konfigurieren. Schnittstellenquellen-NAT eignet sich für die Bearbeitung eingehender Anrufe in einem kleinen Büro, während wir die Einrichtung von Nat-Quellpools für größere Netzwerke oder Unternehmensumgebungen empfehlen.

Hinweis:

Unterstützung eingehender Anrufe über Schnittstellen-NAT oder einen Quell-NAT-Pool wird nur für SIP- und H.323-Dienste unterstützt. Bei eingehenden Anrufen unterstützt Junos OS derzeit nur UDP und TCP. Die Auflösung des Domänennamens wird derzeit ebenfalls nicht unterstützt; daher müssen URIs IP-Adressen enthalten, wie in Abbildung 4 dargestellt.

Abbildung 4: Verwendung des SIP-Registrars