WO2006081877A1 - Verfahren zum routen von internetverbindungen über netzübergänge - Google Patents

Verfahren zum routen von internetverbindungen über netzübergänge Download PDF

Info

Publication number
WO2006081877A1
WO2006081877A1 PCT/EP2005/054476 EP2005054476W WO2006081877A1 WO 2006081877 A1 WO2006081877 A1 WO 2006081877A1 EP 2005054476 W EP2005054476 W EP 2005054476W WO 2006081877 A1 WO2006081877 A1 WO 2006081877A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
gateway
lan
netid
additional information
Prior art date
Application number
PCT/EP2005/054476
Other languages
English (en)
French (fr)
Inventor
Gerhard Otte
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to US11/883,511 priority Critical patent/US20080117923A1/en
Priority to EP05789478A priority patent/EP1844592A1/de
Publication of WO2006081877A1 publication Critical patent/WO2006081877A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2521—Translation architectures other than single NAT servers
    • H04L61/2535—Multiple local networks, e.g. resolving potential IP address conflicts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • IP Internet Protocol
  • the gateway between the LAN and the public network must convert the private IP address to a network-wide unique (global) IP address. This usually happens with a Network Address Translation (NAT) functionality.
  • Network Address Port Translation Functionality (NAPT).
  • the NAT function is a protocol that describes the conversion of IP addresses from one network to another and is used on routers or firewalls. With the NAT function can z. B. a network address 10.0.0.2 to 192.168.0.2, another IP address 10.0.0.3 to 192.168.0.3 etc. be implemented. With NAPT it is possible analogously to translate port numbers.
  • the most common case of using the NAT functionality is the connection of a local area network (i.e., the IP addresses of all machines in a network) via only one official IP address to a public network. This often happens over a firewall. This allows the IP addresses of single or multiple networks to be concealed (mascerading). A private network is represented by a single IP address.
  • the NAT functionality thus on the one hand ensures that the increasingly scarce public IP addresses are extended by additional (private) IP addresses.
  • the NAT functionality of data security is lent, since the internal structure of the network remains hidden to the outside (security aspect).
  • the subscribers of a local network are interpreted in this case as subscribers of different networks. In the event that subscribers use different network cards of a firewall or network. connect multiple firewalls to the public network, this assignment is lost.
  • the (application layer) gateway only recognizes one IP address for two subscribers of a local network, then the RTP data stream is routed locally. If the gateway recognizes two IP addresses, the RTP data stream is routed globally. H . across the gateway. As a consequence, data streams can no longer be kept local in the presence of multiple gateways, even if the nodes are located within a routable network segment.
  • the invention has for its object to provide a way and a device how networks can be clearly identified across gateways away.
  • Network identification number This is common to all participants within a routable network segment. Thus, a downstream entity (NAT traversal, softswitch, ...) can detect whether a data connection between two communication points can be made directly (peer-to-peer).
  • the network identification number (NetID) can be part of a user-specific field within the message or can also be introduced as a naming convention (eg userl @ netID. Siemens. De).
  • the administration of the network identification number can be done via the DHCP process, so all participants get this NetID at the start-up. This information is sent along with the signaling, and is interpreted by the signaling endpoints.
  • a public network ON which communicates with a local area network LAN via two routers R in operative connection.
  • a router R is in each case arranged in a gateway.
  • the two subscriber terminals A, B are to be regarded as part of the local area network LAN.
  • the signaling information of the two subscriber terminals A, B are supplied, for example via a protocol MGCP (Media Gateway Control Protocol) arranged in the public network Call Agent CA.
  • the private IP addresses in the network LAN are assigned by a server S in the context of the DHCP process the terminals as well as the network identification number NetID.
  • the server S is thus also responsible for allocating the network identification number NetID, which is valid for all subscribers of the local network.
  • a gateway IP-IP GW is integrated into the public network ON. The conversion of the private IP addresses to global IP addresses is performed in the routers R.
  • a voice carrier offers a MGCP-based VoIP service for the customers local network LAN.
  • the voice data stream RTP should, if possible, be located within the local network for local calls. be routed. All subscribers of the local network receive from server S both local IP addresses and a network identification number NetID.
  • Subscriber A wishes in the following a VoIP connection to subscriber B. Subscriber A transmits the private IP address together with the network identification number NetID to the call agent CA and the gateway IP IP GW in an MGCP message.
  • the NAT function is executed, which converts the private IP addresses into a public IP address.
  • the users of the LAN network are also assigned several public IP addresses.
  • the gateway IP-IP GW can thus no longer recognize solely on the basis of the IP address as a criterion that an internal RTP connection between the two subscriber terminals A, B of the local area network LAN can be created for a VoIP connection.
  • the gateway IP-IP GW recognizes that the two subscriber terminals A, B are located in the same IP network and creates the RTP connection between the two subscriber terminals A in the local network. B.
  • the advantage of this approach is that the network identification number NetID is given in the payload of the IP packets (Layer 2) and thus the evaluation takes place in the gateway IP-IP GW at the application level.
  • the invention has been described in terms of the MGCP protocol. It is not limited to the MGCP protocol, but any other protocol such as the MEGACO or SIP protocols can be used here. Furthermore, the invention is not limited to VoIP alone as RTP, other data connections can also be run.

Abstract

Damit Teilnehmer eines privaten Netzes mit Teilnehmern eines öffentlichen Netzes kommunizieren können, müssen am Netzüber- gang die privaten IP-Adressen in eine netzweit eindeutige (globale) IP-Adresse umgesetzt werden. Damit erhalten alle Teilnehmer des privaten Netzes im öffentlichen, globalen Netz eine einzige IP-Adresse. Diese ist hier ein eindeutiges Kriterium dafür, das diese Teilnehmer demselben privaten Netz zugehörig sind. Bei Vorhandensein mehrerer Netzübergänge werden den Teilnehmern desselben privaten Netzes mehrere IP-Adressen zugeordnet. Um in diesem Fall dennoch Kenntnis dar- über zu haben, dass diese Teilnehmer demselben privaten Netz zugehören, wird erfindungsgemäß vorgeschlagen, eine Zusatzin- formation vorzusehen, die eindeutig für das private Netz ist und mit der dieses im öffentlichen, globalen Netz jederzeit identifiziert werden kann.

Description

Beschreibung
Verfahren zum Routen von Internetverbindungen über Netzübergänge
In der Welt des Internets sind IP (Internet Protokoll) Adressen begrenzt und teuer . Die Begrenzung rührt daher, dass eine IP-Adresse im öffentlichen Netz weltweit einen eindeutigen Charakter haben muss . Im Unterschied hierzu sind private IP- Adressen zu sehen, die lediglich lokal - also etwa im LAN
(Local Aerea Network) Bereich - eingesetzt werden und keine globale Wirkung entfalten . Private IP-Adressen müssen daher lediglich im LAN Bereich eindeutig sein .
Damit Teilnehmer des LAN mit öffentlichen Teilnehmern kommunizieren können, muss am Netzübergang zwischen LAN und öffentlichem Netz eine Umsetzung der privaten IP-Adresse auf eine netzweit eindeutige (globale) IP-Adresse erfolgen . Dies geschieht in der Regel mit einer Network Address Translation Funktionalität (NAT) bzw . Network Address Port Translation Funktionalität (NAPT) . Die NAT-Funktion ist ein Protokoll welches das Umsetzen von IP-Adressen von einem Netz in ein anderes Netz beschreibt und kommt auf Routern oder Firewalls zum Einsatz . Mit der NAT-Funktion kann z . B . eine Netzadresse 10.0.0.2 zu 192.168.0.2 , eine weitere IP-Adresse 10.0.0.3 zu 192.168.0.3 usw . umgesetzt werden . Mit NAPT ist es analog möglich Portnummern zu übersetzen .
Der häufigste Fall der Verwendung der NAT-Funktionalität ist die Anbindung eines lokalen Netzes (d. h . die IP-Adressen aller Maschinen in einem Netz) über nur eine offizielle IP- Adresse an ein öffentliches Netz . Die geschieht häufig über eine Firewall . Damit lassen sich die IP-Adressen einzelner oder mehrerer Netze verbergen (Mascerading) . Ein privates Netzwerk wird dadurch nach außen hin durch eine einzige IP- Adresse repräsentiert . Durch die NAT-Funktionalität wird somit zum einen erreicht, dass die immer knapper werdenden öffentlichen IP-Adressen um zusätzliche (private) IP-Adressen erweitert werden . Zum anderen ist die NAT-Funktionalität der Datensicherheit dien- lieh, da die interne Struktur des Netzwerk nach außen hin verborgen bleibt (Security Aspekt) .
Durch das Verbergen von IP-Adressen entstehen nun in vielen Bereichen Probleme . Speziell in der VoIP Signalisierung über MGCP/ Megaco/ SIP ist es notwendig, zu erkennen (Security,
Bandwith, ... ) , dass Teilnehmer sich im gleichen Netzsegment befinden . Nur in diesem Fall können Datenströme (RTP) ausschließlich in diesem Segment geroutet werden und bleiben nach außen hin unsichtbar .
Aus diesem Grund existieren beim Stand der Technik Application Layer Gateways (NAT-Traversal Devices ) , die hier elegante Lösung anbieten (insbesondere für Remote Access ) .
Problematisch an diesen Lösungen des Standes der Technik ist, dass die Zuordnung von Teilnehmern zu einem Netzsegment ausschließlich über die IP-Adresse (offizielle IP-Adresse) des Netzüberganges (Firewall) erfolgt . Dies bedeutet, dass die Teilnehmer eines lokalen Netzes im öffentlichen Netz alle dieselbe IP-Adresse haben . Existiert lediglich ein Netzübergang (z . B . über lediglich einen Router/ Firewall, so erkennt das (Application Layer) Gateway, dass alle Teilnehmer mit derselben IP-Adresse (und gegebenenfalls unterschiedlichen Portnummern) zum selben Netz gehören . Ein einziger Netzüber- gang birgt aber die Gefahr eines Flaschenhalses , d. h . alle
Teilnehmer des lokalen Netzes kommunizieren über diesen Netzübergang mit Teilnehmern des öffentlichen Netzes . Dynamikprobleme sind damit vorprogrammiert . Aus diesem Grund sind in der Regel mehrere Netzübergänge vorgesehen . Damit ist die Zuordnung der Teilnehmer zu einem Netzsegment nicht mehr möglich, da allen Netzübergängen unterschiedliche IP-Adressen zugeordnet werden . Da für das (Application Layer) Gateway die IP-Adresse alleiniges
Kriterium ist, werden die Teilnehmer eines lokalen Netzes in diesem Fall als Teilnehmer verschiedener Netze interpretiert . Im Falle, dass sich Teilnehmer über unterschiedliche Netzwerkkarten einer Firewall bzw . mehrere Firewalls an das öffentliche Netz anbinden, geht diese Zuordnung verloren .
Erkennt das (Application Layer) Gateway für zwei Teilnehmer eines lokalen Netzes lediglich eine IP-Adresse, so wird der RTP Datenstrom lokal geroutet . Erkennt das Gateway zwei IP- Adressen, so wird der RTP Datenstrom global geroutet, d. h . über den Netzübergang hinweg . Dies bedeutet als Konsequenz , dass Datenströme bei Vorhandensein mehrerer Netzübergänge nicht mehr lokal gehalten werden können, auch wenn die Teilnehmer sich innerhalb eines routbaren Netzsegments befinden .
Der Erfindung liegt die Aufgabe zugrunde, einen Weg und eine Vorrichtung aufzuzeigen, wie Netze über Netzübergänge hinweg eindeutig identifiziert werden können .
Die Erfindung wird ausgehend von dem in den Oberbegriffen der Patentansprüche 1 und 9 angegebenen Merkmale durch die kennzeichnenden Merkmale gelöst .
Wesentlich für die Erfindung ist, dass eine Zusatzinformation eingeführt wird, welche eine Zuordnung der Teilnehmer zu einem Netzsegment eindeutig identifizierbar macht . Den Teilnehmern wird hierzu eine Netzidentifikationsnummer (NetID) mitgeteilt . Diese ist allen Teilnehmern innerhalb eines routbaren Netzsegments gemeinsam. Somit kann eine nachgeschaltete Instanz (NAT Traversal, Softswitch, ... ) erkennen ob eine Datenverbindung zwischen zwei Kommunikationspunkten direkt (peer-to-peer) erfolgen kann . Die Netzidentifikationsnummer (NetID) kann Bestandteil eines userspezifischen Feldes innerhalb der Nachricht sein, oder auch als Namenskonvention eingeführt werden (z . B . userl@ netID. siemens . de) . Die Adminstration der Netzidentifikations- nummer kann über den DHCP Prozess erfolgen, somit bekommen alle Teilnehmer beim Start-up diese NetID mitgeteilt . Diese Information wird bei der Signalisierung entsprechend mitgesendet, und wird von den Signalisierungsendpunkten interpretiert .
Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben .
Die Erfindung wird im Folgenden anhand eines figürlich darge- stellten Ausführungsbeispiels näher erläutert .
Demgemäss ist ein öffentliches Netz ON aufgezeigt, welches mit einem lokalen Netz LAN über zwei Router R in Wirkverbindung steht . Ein Router R ist j eweils in einem Netzübergang angeordnet . Die beiden Teilnehmerendgeräte A, B sind dabei als Teil des lokalen Netzes LAN zu betrachten . Die Signali- sierungsinformationen der beiden Teilnehmerendgeräte A, B werden beispielhaft über ein Protokoll MGCP (Media Gateway Control Protokoll) einem im öffentlichen Netz angeordneten CaIl Agent CA zugeführt . Die privaten IP-Adressen im Netz LAN werden von einem Server S im Rahmen des DHCP Prozesses den Endgeräten ebenso zugeteilt wie die Netzidentifikationsnummer NetID . Der Server S ist damit auch für das Zuteilen der Netzidentifikationsnummer NetID zuständig, die für alle Teil- nehmer des lokalen Netzes Gültigkeit hat . Schließlich ist in das öffentliche Netz ON ein Gateway IP-IP GW integriert . Die Umsetzung der privaten IP-Adressen zu globalen IP-Adressen wird in den Routern R durchgeführt .
Es wird nun davon ausgegangen, dass ein Voice Carrier einen MGCP basierenden VoIP Service für die Kunden lokalen Netzes LAN anbietet . Dabei soll der Voice Datenstrom RTP bei lokalen Gesprächen nach Möglichkeit innerhalb des lokalen Netzes ge- routet werden . Alle Teilnehmer des lokalen Netzes erhalten vom Server S sowohl lokale IP-Adressen als auch eine Netzidentifikationsnummer NetID . Teilnehmer A wünscht im folgenden eine VoIP Verbindung zu Teilnehmer B . Teilnehmer A über- gibt in einer MGCP Nachricht die private IP-Adresse zusammen mit der Netzidentifikationsnummer NetID dem CaIl Agent CA und dem Gateway IP-IP GW. Im Router R gelangt die NAT-Funktion zum Ablauf, die die privaten IP-Adressen in eine öffentliche IP-Adresse umsetzt .
Da mehrer Netzübergänge vorhanden sind, werden den Teilnehmern des Netzes LAN auch mehrere öffentliche IP-Adressen zugeordnet . Das Gateway IP-IP GW kann somit allein aufgrund der IP-Adresse als Kriterium nicht mehr erkennen, dass für eine VoIP Verbindung eine interne RTP Verbindung zwischen den beiden Teilnehmerendgeräten A, B des lokalen Netzes LAN erstellt werden kann .
Durch die mitgegebene Zusatzinformation, die als Netzidenti- fikationsnummer NetID ausgebildet ist, erkennt das Gateway IP-IP GW, dass die beiden Teilnehmerendgeräte A, B sich im gleichen IP-Netz befinden und erstellt im lokalen Netz die RTP Verbindung zwischen den beiden Teilnehmerendgeräte A, B .
Der Vorteil dieser Vorgehensweise liegt darin, dass die Netzidentifikationsnummer NetID in der Payload der IP-Pakete (Layer 2 ) mitgegeben wird und damit die Auswertung im Gateway IP-IP GW auf Applikationsebene erfolgt .
Die Erfindung wurde anhand des MGCP Protokolls beschrieben . Sie ist nicht auf das Protokoll MGCP beschränkt, hier kann auch j edes andere Protokoll wie beispielsweise die Protokolle MEGACO oder SIP verwendet werden . Ferner ist die Erfindung nicht allein auf VoIP als RTP begrenzt, andere Datenverbind- ungen können ebenso zum Ablauf gelangen .

Claims

Patentansprüche
1. Verfahren zum Identifizieren von Netzen über wenigstens einen Netzübergang hinweg, der zwischen einem ersten Netz (LAN) und einem zweiten Netz (ON) angeordnet ist, dadurch gekennzeichnet, dass eine für das erste Netz (LAN) eindeutige Zusatzinformation (NetID) vorgesehen wird, über die das erste Netz (LAN) eindeutig im zweiten Netz (ON) identifizierbar ist .
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass eine Kommunikation zwischen wenigstens zwei Teilnehmern (A, B) des ersten Netzes (LAN) nach Maßgabe der Zusatzinfor- mation (NetID) über den wenigstens einen Netzübergang hinweg vom zweiten Netz (ON) aus gesteuert wird.
3. Verfahren nach Anspruch 1 , 2 , dadurch gekennzeichnet, dass die Kommunikation zwischen den wenigstens zwei Teilnehmern (A, B) von einem im zweiten Netz (ON) angeordneten Gateway (IP-IP GW) gesteuert wird.
4. Verfahren nach Anspruch 1 bis 3, dadurch gekennzeichnet, dass die Zusatzinformation (NetID) von einem DHCP Server (S) erstellt wird.
5. Verfahren nach Anspruch 1 bis 4 , dadurch gekennzeichnet, dass , falls die wenigstens zwei Teilnehmer (A, B) im selben ersten Netz (LAN) angeordnet sind, die Bearerverbindung (RTP) direkt innerhalb dieses Netzes (LAN) erstellt wird.
6. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Zusatzinformation (NetID) im Übertragungsprotokoll (MGCP, MEGACO, SIP) mitgeführt wird.
7. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Netzidentifikationsnummer (NetID) Bestandteil eines userspezifischen Feldes innerhalb der Protokollnachricht ist .
8. Verfahren nach einem Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Netzidentifikationsnummer (NetID) als Namenskonvention ausgebildet ist (z . B . userl@ ΩetJD. siemens . de) .
9. Gateway zum Routen von Internetverbindungen über einen Netzübergang in einem ersten Netz (LAN) , wobei das Gateway
(IP-IP GW) in einem zweiten (ON) Netz angeordnet ist, dadurch gekennzeichnet, dass das Gateway nach Maßgabe einer für das erste Netz (LAN) eindeutigen Zusatzinformation (NetID) eine Kommunikation zwischen wenigstens zwei Teilnehmern (A, B) des ersten Netzes steuert .
PCT/EP2005/054476 2005-02-03 2005-09-09 Verfahren zum routen von internetverbindungen über netzübergänge WO2006081877A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/883,511 US20080117923A1 (en) 2005-02-03 2005-09-09 Method for Routing Internet Connections Via Network Gateways
EP05789478A EP1844592A1 (de) 2005-02-03 2005-09-09 Verfahren zum routen von internetverbindungen ]ber netz]berg[nge

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005005083 2005-02-03
DE102005005083.2 2005-02-03

Publications (1)

Publication Number Publication Date
WO2006081877A1 true WO2006081877A1 (de) 2006-08-10

Family

ID=35169610

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/054476 WO2006081877A1 (de) 2005-02-03 2005-09-09 Verfahren zum routen von internetverbindungen über netzübergänge

Country Status (4)

Country Link
US (1) US20080117923A1 (de)
EP (1) EP1844592A1 (de)
CN (2) CN101116303A (de)
WO (1) WO2006081877A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8844018B2 (en) * 2008-12-18 2014-09-23 At&T Intellectual Property I, L.P. Methods and apparatus to enhance security in residential networks
US10530461B2 (en) * 2015-03-25 2020-01-07 Qualcomm Incorporated Relay discovery and association messages
CN106302861B (zh) * 2016-09-27 2020-04-17 新华三技术有限公司 一种地址分配方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040139230A1 (en) * 2002-12-27 2004-07-15 Lg Electronics Inc. SIP service method in a network having a NAT
US20050008024A1 (en) * 2003-06-27 2005-01-13 Marconi Communications, Inc. Gateway and method

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6308328B1 (en) * 1997-01-17 2001-10-23 Scientific-Atlanta, Inc. Usage statistics collection for a cable data delivery system
US7437474B2 (en) * 2001-02-22 2008-10-14 Intel Corporation Proxy-less packet routing between private and public address realms
US8363647B2 (en) * 2001-04-03 2013-01-29 Voxpath Networks, Inc. System and method for configuring an IP telephony device
US20020186698A1 (en) * 2001-06-12 2002-12-12 Glen Ceniza System to map remote lan hosts to local IP addresses
US7360242B2 (en) * 2001-11-19 2008-04-15 Stonesoft Corporation Personal firewall with location detection
US20030110379A1 (en) * 2001-12-07 2003-06-12 Tatu Ylonen Application gateway system, and method for maintaining security in a packet-switched information network
US7139841B1 (en) * 2002-07-24 2006-11-21 Cisco Technology, Inc. Method and apparatus for handling embedded address in data sent through multiple network address translation (NAT) devices
US7805606B2 (en) * 2002-07-29 2010-09-28 Bea Systems, Inc. Computer system for authenticating a computing device
FR2847097B1 (fr) * 2002-11-08 2005-04-01 Cit Alcatel Procede pour attribuer a un terminal un identifiant de reseau virtuel; terminal, serveur de configuration dynamique d'un hote, et serveur d'annuaire pour la mise en oeuvre de ce procede
US9363709B2 (en) * 2002-12-24 2016-06-07 Samrat Vasisht Method, system and device for automatically configuring a communications network
KR20040082655A (ko) * 2003-03-19 2004-09-30 삼성전자주식회사 이중 스택 변환 메커니즘을 이용한 모바일 아이피 통신시스템 및 방법
US7313145B1 (en) * 2003-05-28 2007-12-25 Nortel Networks Limited Method and system for establishing paths between end points in packet data networks
IL156924A (en) * 2003-07-15 2009-05-04 Tadiran Telecom Ltd Communication between users located behind nat device
US7990948B2 (en) * 2003-08-15 2011-08-02 Quintence Properties Kg, Llc Serverless and switchless internet protocol telephony system and method
US7411975B1 (en) * 2004-08-26 2008-08-12 Juniper Networks, Inc. Multimedia over internet protocol border controller for network-based virtual private networks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040139230A1 (en) * 2002-12-27 2004-07-15 Lg Electronics Inc. SIP service method in a network having a NAT
US20050008024A1 (en) * 2003-06-27 2005-01-13 Marconi Communications, Inc. Gateway and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
THERNELIUS F: "SIP, NAT, and Firewalls", ERICSSON-DEPARTMENT OF TELEINFORMATICS, May 2000 (2000-05-01), XP002209773 *

Also Published As

Publication number Publication date
EP1844592A1 (de) 2007-10-17
CN103002066A (zh) 2013-03-27
US20080117923A1 (en) 2008-05-22
CN101116303A (zh) 2008-01-30

Similar Documents

Publication Publication Date Title
EP1193919B1 (de) Verfahren zum Verbindungsaufbau von einem Endgerät eines Kommunikationsnetzes zu einem netzexternen Verbindungsziel und Einrichtungen zur Realisierung des Verfahrens
EP2193649B1 (de) Verfahren und Vorrichtung zur Verbindung paketorientierter Kommunikationsendgeräte
DE10353925A1 (de) Verfahren zum Austausch von Daten zwischen zwei Hosts
EP1491032A1 (de) Steuerung einer sprachkommunikationsverbindung in einem paketvermittelnden kommunikationsnetz zwischen unterschiedlichen domänen zugeordneten kommunikationseinrichtungen
WO2006081877A1 (de) Verfahren zum routen von internetverbindungen über netzübergänge
EP1897340A1 (de) Vorrichtung und verfahren zum adress-mapping
EP1878205B1 (de) Verfahren und vorrichtung zur umsetzung von internet-protokoll-adressen innerhalb eines kommunikationsnetzwerkes
DE10329877A1 (de) Verfahren zum Betrieb eines Sprach-Endgerätes an einer abgesetzten Nebenstellenanlage, Kommunikationsanordnung und Sprach-Endgerät
DE60314255T2 (de) Signalisierung einer trägerverbindung in einer verteilten architektur
EP1430693B1 (de) Verfahren und vorrichtung zur realisierung einer firewallanwendung für kommunikationsdaten
EP2036313B1 (de) Verfahren zur verwaltung von kommunikationsverbindungen über netzwerk-adressumsetzende nat netzknoten
DE10321227A1 (de) Verfahren zum Datenaustausch zwischen Netzelementen
DE10250201B4 (de) Verfahren und Vorrichtung zum Austausch von Daten mittels einer Tunnelverbindung
DE10245547B3 (de) Verfahren zum Aufbau einer VoIP-Telefonverbindung in einem gesicherten Netzwerk sowie Schaltungsanordnung
DE102007046561A1 (de) Verfahren zur Auswahl von Dienstgüteklassen in Verbindungen zwischen Endgeräten und einem Internet Gateway
DE102008009925B4 (de) Verfahren und Einrichtung zum Verbindungsaufbau für die Internettelefonie
EP1543670B1 (de) Verfahren zum transparenten austausch von datenpaketen
EP1383295B1 (de) Verfahren zur Adressumsetzung in Paketnetzen und Adressumsetzer für Kommunikationsnetzwerke
DE102006017940B4 (de) Verfahren zur Herstellung einer Verbindung
DE60118572T2 (de) Adressenübersetzungssystem für ein Paketnetzwerk
EP1856885A1 (de) Verfahren zum aufbau von multimediaverbindungen über grenzen von paketvermittelnden kommunikationsnetzen
DE102007001408A1 (de) Verfahren und Kommunikationsanordnung zum Transport von Multimediadaten zwischen IP-Endgeräten in einem lokalen Netz eines WAN
EP1924072A1 (de) Aufbau einer Kommunikationsverbindung in einem privaten IP-Netzwerk ohne Kontaktierung eines öffentlichen STUN-Servers
EP1522183B1 (de) Verfahren zur Adressumsetzung in Paketnetzen und Steuerelement für Kommunikationsnetzwerke
WO2008034782A1 (de) Verfahren zur erzeugung einer externen internet-protokoll-adresse zur verwendung als zieladresse einer reserve-external-address-nachricht

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005789478

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11883511

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 200580047742.9

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2005789478

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11883511

Country of ref document: US