|Publication number||USRE43057 E1|
|Application number||US 11/299,236|
|Publication date||Jan 3, 2012|
|Filing date||Dec 9, 2005|
|Priority date||Sep 13, 2000|
|Also published as||CN1531801A, CN100512165C, CN101668051A, CN101668051B, DE60127276D1, DE60127276T2, DE60138058D1, EP1323261A1, EP1323261A4, EP1323261B1, EP1793533A1, EP1793533B1, EP1793533B8, EP2068499A1, EP2068499B1, US6661799, USRE44593, WO2002023822A1|
|Publication number||11299236, 299236, US RE43057 E1, US RE43057E1, US-E1-RE43057, USRE43057 E1, USRE43057E1|
|Inventors||Andrew T. Molitor|
|Original Assignee||Alcatel Lucent|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (34), Non-Patent Citations (31), Referenced by (2), Classifications (25), Legal Events (8)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present application is a broadening reissue application of and claiming priority to U.S. Pat. No. 6,661,799 entitled “Method and Apparatus for Facilitating Peer-to-Peer Application Communication” issued on Dec. 9, 2003, application Ser. No. 09/661,070, filed Sep. 13, 2000, which is hereby incorporated by reference herein.
1. Field of the Invention
This invention relates to devices for handling communications between applications exchanging data over the Internet. More particularly, this invention relates to a Network Address Translation (NAT) device and a system and method using such NAT device for facilitating peer-to-peer commu-nication of data over the Internet.
2. Description of the Prior Art
As shown in
One solution is for the organization to have allocated to it some set of official IP addresses. These are unique addresses. Any application on the Global Internet sending data to these addresses may rely on that data arriving at the entrance to the organization's internal network. That is, the Global Internet infrastructure will correctly deliver data to the organization, and then (as is the normal case with IP) rely on the organization to locate the right end point endpoint application inside the organization for final delivery.
The organization could then assign each of the official IP addresses it has been allocated to an individual application for an indefinite period, allowing a lucky few applications Internet access. A better solution, allowing wider access, is to use a device that can, in effect, assign the officially allocated IP addresses dynamically to whichever applications need access to the Global Internet at any given time. Addresses are recovered from applications no longer using them, and made available for reassignment. This sharing system works very well and is, in the simplest form, exactly what a conventional NetworkAddress Translator (NAT) usually does. (See RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations, published by the Internet Engineering Task Force (IETF). This is the basic IETF document describing the operation and issues surrounding NAT devices.) Often, an organization will be assigned some very small number of official IP addresses. Perhaps as few as 31, or 255 such addresses may be given to an organization. For an organization with thousands of applications on its internal network, a naīve NAT, able only to assign official IP addresses, may not be enough. If only 31 of, say, 5000 applications (each of which might correspond to an individual employee) can be using the Global Internet at once, the problem may not be considered fully solved.
In order to effectively expand the useful size of the officially allocated address pool, the organization's NAT will usually have the ability to use the same official address for multiple internal applications. Data arriving for a specific official IP address, say, X, may be further distinguished by belonging to one of several data streams, say A, B and C. The NAT may have assigned address X, stream A to a specific data stream for one application, while address X streams B and C belong to two different, other applications.
The stream identifiers are called port numbers. A stream of data in an IP network is uniquely identified by the so-called “5-tuple”, which consists of 5 separate numeric quantities:
Every data item (packet) in an IP network has these 5 numeric identifiers in it. The two IP addresses (items 1 and 2 above) identify, more or less, the source and destination applications. The protocol identifies which of the mechanisms for ensuring reliable transport of data are being used. For present purposes the protocol is ignored, because it is not something a NAT does much with. The source and destination ports (items 3 and 4 above) identify which application within the network sent and is to receive, respectively, this packet.
A conventional Network Address Translator (e.g., a Private Internet Exchange (PIX), made by Cisco Systems, Inc. of San Jose, Calif.) as viewed by this document operates by altering these five numeric identifiers within a packet. As noted above, a NAT device resides at the boundary between two address realms, usually, but not always, the Global Internet and an organization's private network, where these two networks have incompatible IP addressing schemes. A NAT device uses intelligent re-writing of the four source/destination elements within each packet flowing through it, to present to each of the two networks a false but compatible view of the other network's IP addressing scheme. Each NAT must have a set of rules defining the internal address-external address pairing it will use for address translation. A useful NAT must build these pairings to allow internal applications to make effective use of available external addresses, which will be limited if the external realm requires official IP addresses.
A conventional NAT device associated with an internal network supports, essentially, two concurrent modes of operation. The first allows data transactions from applications on the internal network outwards to the Global Internet (for example, a corporate user accessing a web page). This is an Internal Client to External Server access. The second allows applications on the Global Internet to access specific services on specific devices on the internal network (for example, a customer accessing an organization's web site). This is External Client to Internal Server access. The way in which the conventional NAT device builds the address pairing that allows the first and second type of access are somewhat different.
A conventional NAT device implements the first mode as follows: when the initial packet of a data transaction arrives on the NAT device outbound, the NAT device examines the source address and port (which identify the internal device and the application that originated the packet). The NAT then chooses from its pool of available official addresses and ports an externally-valid IP address and port to use in place of the internally-valid source address and port in the packet. The mapping from the internally-valid source address and port to the externally-valid source address and port is maintained somehow within the NAT, for example, in a table defining the correspondence rule. Finally, the NAT modifies the internally-valid source address and port fields in the outbound packet, and sends it on. When an inbound reply packet, responding to the initial packet, turns up at the NAT from the outside, the destination address and port in the reply packet will match the externally-valid source address and port (because in a reply, naturally, the sender address and the recipient address change places, exactly as with, say, a postal letter). The NAT uses this incoming externally-valid source address and port to locate the internally-valid source address and port from the initial, outbound packet. The NAT then uses the located, internally valid source address and port to replace the destination address and port in this incoming reply packet. Now the incoming reply packet has the correct internally-valid destination address and port for delivery to the device and application which sent the initial outbound packet.
A conventional NAT device implements the second mode using fixed internal-external address correspondence configuration information, defined by the person administrating the NAT. For this mode, the initial packet will be incoming, arriving at the NAT from the outside, with some destination information containing an IP address among those officially allocated, because these externally-valid addresses are the only IP addresses the Global Internet can use to deliver packets to the target organization with the NAT. The NAT at the target organization consults its configuration information to determine which (fixed) internally-valid destination IP address and port it should use to replace the externally valid destination address and port contained in the incoming packet. In effect, if an application (say, a web server) is present at the target organization on internal device A (a non-official, but internally-valid IP address), expecting packets on port X, the NAT might be configured to recognize that packets addressed to IP address M (officially assigned and externally-valid), port Y should be re-addressed to the internally-valid address, device A/port X. Another application at the target organization might be running on another internal device, externally identified as device B, at port Z, and the NAT might use an internal-external address pairing for this application using the same internal address A and some other port, again according to some fixed, pre-defined configuration data.
The difficulty is that the first mode only allows Internal Clients to send data to (and thereafter receive data from) External Servers, while the second only allows External Clients to send data to (and thereafter receive replies from) a small set of Internal Servers at fixed IP addresses and ports, pre-defined in the NAT associated with the Internal Servers. Transactions in which an External Client connects to a just-created Internal Server at a just-allocated port number are not supported.
A variety of prior art references discuss NAT devices and variations on their basic address translation functions:
U.S. Pat. No. 6,055,236, titled “Method And System For Locating Network Services With Distributed Network Address Translation,” covers methods for, in effect, advertising a service securely. U.S. Pat. No. 6,055,236 is silent on the symmetrical issue of providing addresses for Client-side information, focusing entirely on advertising externally useful addresses for servers and saying nothing regarding external addresses to be used by clients.
U.S. Pat. No. 5,793,763, titled “Security System For Network Address Translation Systems” is a patent on a NAT device of sorts, except that it only translates IP addresses and it is concerned with security considerations. There is nothing taught on the subject of using port numbers to expand the “logical” address space available.
SOCKS. SOCKS is an Internet Engineering Task Force (IETF) standard, which provides a mechanism by which an application can query an application fire wall firewall as to an externally useful address which it can advertise to a remote client application. SOCKS is this application's proxy, which provides services similar to a NAT, but operates quite differently. Rather than re-writing the packet contents as it flows through the device, SOCKS (like any application proxy) will terminate two communication channels, and logically connect them together at a high layer inside itself. For example, a server on the inside of a network might start its service, and then make a request to a SOCKS application at the edge of the network. The SOCKS application will start a “thin” server on its host, at the network edge, and then inform the original server of the address and port at which the “thin” server may be found. The original server can communicate this information to the client, which connects to the “thin” server which SOCKS is operating. SOCKS will then connect to the original server as a client, and then copy data received from the external client to the original server, as well as copying data received from the original server back out to the external client. In particular, SOCKS is not a NAT and does not operate packet-by-packet, which has certain performance and scaling implications. For more information on SOCKS, see http://www.socks.nec.com.
It is expected that there will be an increase in use of IP networks to send data that consists of digitized voice, sound or video (“media” content). What is needed is a method and apparatus for network address translation facilitating peer-to-peer data exchange, including media transmission, over the Internet and other IP networks.
This invention comprises a network address translation device for facilitating communication between a first application in a first address realm and a second application in a different address realm. The device uses an address translator for translating an address valid in the first address realm into an address valid in the second address realm, based on a translation rule and for translating the address valid in the second address realm into the address valid in the first realm. It also uses an address manager for establishing a translation rule by associating an address valid in the first address realm with an address valid in the second address realm. There is a control channel communicating with the address manager for receiving from the first application a request for an address valid in the second address realm to be associated with a specified address valid in the first realm and for providing the first application access to the address valid in the second address realm to facilitate communication of the address valid in the second realm to the second application.
In one embodiment of the invention the applications are entities connected for IP telephony. In another embodiment of the invention the address manager establishes more complex translation rules such that an externally valid destination address could be translated into an internally valid address of one value or a different value depending on the incoming source address. Specific remote addresses, larger sets of remote addresses, or any remote address at all could be used as the triggers for the use of special, more complex NAT rules. In a further embodiment an application is programmed to control, within specified ranges, the translation rules established by the address manager.
A system using the present invention is useful for, at least, the new class of Internet applications that operate in a peer-to-peer (two or more devices located anywhere and communicating essentially symmetrically) fashion as opposed to the traditional model in which one device is at a well-known location (IP address), and the other may or may not be located at a well-known location (IP address).
The new generation of Internet Applications such as IP Telephony, Instant Messaging, and so on, allow users on networks in different address realms to connect directly to one another's computers to share data or to collaborate, or just to chat in a continuous, real-time interaction. In these protocols, each user's computer will set up an application that might be termed a micro-server, and then communicate to the other computer, located in a different address realm, an IP address and port at which that micro-server can be reached. (This is the “just-created Internal Server” at the “just-allocated port number” which a conventional NAT device does not handle). To complete the peer-to-peer connection, each user's computer then launches a client application to connect to the micro-server in the other's address realm. The respective client applications must then be put in possession of an address at which the micro-server on the other computer in the other's address realm can be reached. Thereafter, two-way communication between the two client/micro-server pairs can commence, using the NAT to handle the different address realms.
As noted above,
Peer-to-peer applications will not work through a current generation NAT device, in part because of the limited way an application and its corresponding NAT communicate. Normally, a NAT device deals only with the IP address fields of message packets, performing address translation according to a limited set of rules.
Host R's reply packet 250 will use externally valid IP addresses in its address header 260. The NAT 120 will need to translate these externally valid addresses into internally valid IP addresses for its address realm 100. Again, the NAT will use hardware and software 122 that apply its translation rules, stored in any form, such as a correspondence table 124. The result transmitted to Host A from Host R is an internally valid packet 150 with appropriately-translated address header 160 that has an internally valid destination address and port, (i.e., the terminating address for Application A1). This permits the internally valid packet 150 with data content 162 to reach Application A1.
The micro-servers for the peer-to-peer communication facilitated by the present invention reside, potentially, on any host device within an organization's internal network. These micro-servers generally will be assigned a random, available port number by the underlying operating system (in an operating system specific way) as the port to use for its service; this will be a number currently not in use by any other application on the host device where the micro-servers server runs. Indeed, there is no reason the micro-server needs to reside on the same device as the application communicating the micro-server's address, nor is there a need for the micro-server's client in the other address realm to reside on the same device as the device to which the micro-server's address is to be communicated to set up data exchange. However, if this separation does occur, some intra-network communication must occur so that all the applications will know all the address and port information they need to know.
We will refer to the class of applications discussed herein as “peer-to-peer applications,” which is intended to cover all applications in which two applications communicate over a network in an essentially symmetric fashion, where neither application is clearly a server or a client in the sense of an application providing a service or receiving a service, respectively; rather, both applications perform the same or similar functions on behalf of the other. Note that throughout the rest of this document we use the term “client” to mean an application which initiates a data transfer session, and the term “server” to mean an application which accepts the initiation of a data transfer session from a client. This is convenient terminology, which helps to define in which direction the initial data packet passing between two applications passes. This initiation step is important for a discussion of NAT behavior. For our purposes, unless otherwise stated, the term “client” will mean the application or device sending the initial session packet of a data transfer, and “server” will mean the application or device to which that initial packet is directed.
IP Telephony is an important example of a peer-to-peer application. In this example each end point endpoint application acts as a client by initiating a so-called “media” connection to send packets containing digitized voice to the other, which receives the packets containing digitized voice as a server. The relationship is more or less symmetrical, as digitized voice normally passes in both directions.
In IP telephony, a micro-server on an internal network (say, an IP telephone awaiting a stream of digitized voice packets from a remote telephone) will usually need to communicate its host device's IP address to a remote client (the other IP telephone, or some other device, such as a virtual PBX or other IP telephony gateway acting on behalf of the other telephone). The micro-server's internally valid network address won't work for a client on the Global Internet, because this address is not an officially assigned IP address. In the event that the micro-server could somehow independently discover or compute an official IP address, which it could communicate to the remote client in the initial packet, the conventional NAT would still have no procedures or rules for what to do with the first reply packet as sent by the remote client application. That is, unless, the NAT itself took part in this discovery or computation of the official IP address in the initial packet, the NAT will have no translation rule associating the internal network address and any official IP address in an incoming message.
The following discussion makes reference to
Efficient peer-to-peer application communication between different address realms requires that the applications (for simplicity, we will confine discussion to two applications exchanging data between them, as opposed to a one-to-many or many-to-many exchange) have access to the official, externally-valid IP address information that will be used in their communication. In the simplest case, a first application needs to have access to (1) the externally-valid address information others will use to reach it, so that such first application can communicate that address information to a second application in another address realm, and (2) the externally valid address of the second application. In fact, for symmetry and to facilitate security and other functions, it is better that each of the first and second applications has two addresses: an originating address AO, used to identify the device and port of a sending application as the source of an outbound message packet, and a separate terminating address, AT, used to identify another device and port that will receive inbound message packets. Thus, ideally communication is established by each of the first and second applications having and communicating two associated official addresses: originating and terminating. In addition, each of the first and second applications has access to the originating and terminating addresses of the counterpart with which it wants to have peer-to-peer communication.
Improved NAT 320 serves the address realm 100. Improved NAT 320 has two functional sections. One is the address translation section 322, which performs the conventional address translation functions as discussed with respect to NAT 120 in
The address translation section 322 is connected to the “outside” address realms. By way of example,
A control channel 350 connects Host A 110 (and indirectly Host B 310) to the address manager section 324. The control channel 350 is used when an application on Host A or any other host served by NAT 320 needs to communicate with NAT 320 to request services of the address manager 324. The address manager can perform several services for a requesting application. First, a requesting application can present an internally-valid address (either an originating address or a terminating address), and ask the address manager 324 to provide an externally valid address paired with the internally valid address and give the address translation section 322 access to this pairing. This can be done so that the address translation section 322 will use this correspondence as its translation rule for incoming and outgoing message packets.
Second, an application may cause the address manager 324 to add additional or more complex translation rules to those used in the NAT 320, going beyond simple internal/external pairings. For example, instead of just performing an unconditional substitution of a corresponding internally-valid destination address or port for a specified externally-valid destination address or port found in an incoming message, a more complex translation rule can be built by the address manager 324 at an application's request. A rule could be formulated so that the address translation section 322 checks the incoming source address and/or port and applies a different translation rule depending on the content of that field. eE.g., externally valid address AE in a packet received at NAT 320 is translated into internally valid address A11, if a certain source address is present in the packet; but no translation is done and the packet is discarded if that source address is not present. This may be useful for security. Alternatively, an externally valid destination port number PE could be translated into an internally valid port number of one value P11, or a different value P12 depending on the incoming source address. Specific remote addresses, larger sets of remote addresses, or any remote source address at all could be used as the triggers for the use of special NAT rules.
Third, an application could specify to the address manager 324 required or desired characteristics for an externally-valid address requested for association with an internally-valid address. This could be useful to let an application specify that the external IP address to result from translation must be a particular IP address or within a specified range of IP addresses. Thus, with an appropriate request, the application could establish a NAT rule that would require that the message packet be directed or forced to a particular external server in the public Global Internet that, in turn, would direct the message to a particular private network where a certain type of transmission or billing could occur before the packet was forwarded again into a public Global Internet.
It can be seen then that the control channel 350 and the address manager section 324 represent a flexible facility for providing applications both information that they do not get with a conventional NAT and the power to establish certain translation rules for the address translation section 322 of the NAT. The address manager 324 can be implemented in hardware or software or a combination of both. For example, it may desirable that the address manager 324 have its own microprocessor and memory for storing the code that determines what services and functions are available in response to control messages from an application. It will further be seen that each application that communicates with the address manager 324 requires hardware and/or software that permits requests to be made over the control channel 350 and requested information or status information returned to the application.
Returning to the above discussion of server and client-relationships, the function of the control channel 350 and communications between an application and the address manager section 324 and address translation section 322 in several different example situations can be explained. Each example is presented in reference to
Server Address/Port Allocation and Discovery Example:
Host A 110 in address realm 100 starts a micro-server, an Application A1 121 that has the purpose of communicating address information to Host R 410, in address realm 200 outside of address realm 100, which address information Host R 410 can use to connect to the micro-server, Application A1. In order to provide Host R with useful address information, the following steps occur:
The external Host R 410 in address realm 200 starts a microserver, e.g., an Application R1 421. Application A1 has the intention of communicating address information to Host R, in address realm 200 outside of address realm 100, which address information Host R can use to validate an incoming connection from Host A. In order to provide Host R 420 with useful address information, the following steps occur:
In this example, Host A and Host B make use of a communication channel 370 between them. This permits an application on Host A to act as a proxy for an application on Host B. For example, if applications on Host B are IP telephones without much intelligence, then Host A could be a virtual PBX with applications that could address a variety of services (e.g., directory assistance, telephone number to IP address association) needed by an IP telephone or could be some other form of IP telephony gateway. With the use of a proxy, it is evident that there need be no relationship between the addresses and ports actually owned or used by the requesting entity, and those addresses and ports called out in the requests to the address manager 324.
Host B 310 in address realm 100 starts a micro-server, e.g., an Application B1 321 that has the purpose of communicating address information to Host R, in address realm 200 outside of address realm 100, which address information Host R (which will act as the client) can use to connect to the micro-server, Application B1 . In order to provide Host R with useful address information, the following steps occur:
Application A1 contacts the NAT device 320 over the control channel 350 to inform the address manager 324 of the internally valid IP address and port Application B1 is using;
In this example, Host R 410 and Host S 510 make use of a communication channel 470 between them. This permits an application on Host R 410 to act as a proxy for an application on Host S 510 . For example, if applications on Host S are IP telephones without much intelligence, then Host R 410 could be a virtual PBX with applications that could address a variety of services (e.g., directory assistance, telephone number to IP address association) needed by an IP telephone or could be some other form of IP telephony gateway.
Host S 510 in address realm 100 starts a micro-server, e.g., an Application 51. Application B1 has the intention of communicating address information to Host S 510, in address realm 200 outside of address realm 100, which address information Host S 510 can use to validate an incoming connection from Host B. In order to provide Host S 510 with useful address information, the following steps occur:
7. Application B1 321 then initiates the connection by sending an outgoing packet addressed to Host S, Application S1 521, which packet arrives at the address translation section 322 of NAT device 320.
A. Without NAT
To explain in greater detail the application of the present invention to IP telephony it is helpful to explain how a simple phone call using a protocol called SIP might work. SIP is the Session Initiation Protocol, but is a generally accepted shorthand for SIP and all the related protocols that work together to allow users to do telephony (and some other things) over data networks, like IP.
In a simple example, there are basically two messages that get sent to establish a phone call. (This discussion suppresses certain detail; there may in fact be quite a bit more going on.) The two messages we are concerned with are the INVITE message, and the OK response to it.
Assume that someone, using a SIP telephone designated Phone A wishes to make a telephone call to someone else, possibly identified by a telephone number, or some other identifier such as an email address. The person making the call would enter the desired target party by typing in the phone number or other identifier. Of course, Phone A doesn't know anything about where the target party is, but it does know where a smarter device called a proxy server is. Phone A therefore formulates an INVITE message which includes information about who the target is, some other information and—significantly—destination information about where Phone A expects to receive media packets from the target whenever the target is located, rung, and picks up the phone. Phone A will typically supply this information in the form of its own IP address, and a port number. Let us imagine that these are 188.8.131.52, and 1111, respectively.
The proxy server contacted by Phone A will probably send the INVITE on to other proxy server devices, following some network search path, until the target is located. At this point, the INVITE message originally formulated by Phone A is delivered to the target, which we will designate as Phone B. Phone B will presumably ring for a while, and (with luck) someone will pick it up. At this point Phone B replies with an OK message, which includes a variety of information, including the destination address at which Phone B expects to receive media. Let's imagine this is IP address 184.108.40.206, port number 2222.
Phone B may begin to send media packets with digitized voice to 220.127.116.11/1111 immediately, because it received this information in the INVITE message. When the OK message returns (through the proxy servers) to Phone A, that phone may begin to send similar media packets to 18.104.22.168/2222. Digital audio data is being sent in both directions at this point, and conversation presumably ensues.
B. With NAT
With a NAT device in the picture, we have three cases to be discussed. In the first case, the target phone is eventually located by the proxy servers inside some NAT device. In the second, the source phone is located inside some NAT device. In the third case, neither phone is located “inside” a NAT device, but the media traffic between them needs to traverse a network located inside a NAT device. In the examples discussed below, all NAT devices are of the kind discuss in
The various cases may be combined, of course. In general, some proxy server will provide to other proxy servers in the network, as well as to the phones involved, the illusion that there are no NAT devices. Because this can be done successfully, you can actually have many NAT devices working with many proxy servers, each convinced that it is the only NAT, and each convincing the rest of the network that, in effect, “there is no NAT here.”
1. Target Phone is Inside a NAT
In this case, the target phone, Phone B, which is inside the address realm of a NAT, will have no problem sending data to the originating phone, because a NAT generally provides things “inside” with the ability to simply send traffic out to anywhere, by addressing it to the outside address. The difficulty is in sorting out what to tell the originating phone, because the target phone is “inside” a NAT, it cannot be reached from the outside without some help from the NAT. The target phone does not use a globally routably IP address; it probably uses a private IP address, an address the rest of the world has no idea how to deliver packets to. Only devices on the target phone's local network can address data to the target phone's actual IP address with any hope of having data delivered to it.
In this case, a proxy server within the target phone's network must be involved. Of course, it will always be involved anyway, because it has responsibility for routing the INVITE to the correct phone within the local network, to complete the call. This proxy server will also process the OK response from the target phone. Remember that the target phone writes its address and port, 22.214.171.124/2222, into this OK message. In this case, 126.96.36.199 is not a useful address for the originating phone, because it is private and only internally valid. The proxy server must, therefore, obtain a different, externally valid address, and replace the address (and possibly port) contained in the OK message before sending it back toward the originating phone.
The proxy server will make a request to the NAT device of the target phone, a “Server Address/Port Allocation/Discovery” request. The NAT will reply with an address and port, say 188.8.131.52/3333, by which devices on the other side (the “outside”) of the NAT device may reach a device at 184.108.40.206/2222 (the target phone). The proxy server re-writes the OK message to indicate 220.127.116.11/3333 instead of 18.104.22.168/2222, and sends this new OK message off to Phone A.
Now when Phone B sends a media packet to Phone A it is addressed to 22.214.171.124/1111, and the NAT allows this to work just fine—outbound traffic can be simply addressed to the “right”, externally valid address. When Phone A sends a media packet to Phone B, however, it will send it to 126.96.36.199/3333—the destination end point endpoint information it received in the OK message. Assuming correct configuration, this packet will arrive at the NAT device, which will translate it so that it is now addressed to 188.8.131.52/2222, per the request made by the proxy server, and sent inside the network. The media packet is now correctly addressed, and is within the local network which knows how to deliver this “privately addressed” media packet, so the media packet arrives at Phone B, as desired.
2. Target Phone is Outside the NAT
This is almost exactly the same as the previous example, except that in this case the proxy server near Phone A (which is now the phone “inside” the NAT, and which has a private IP address useful only within its local network) must re-write the INVITE message after querying the NAT device for an externally valid address. Perhaps the 184.108.40.206/1111 address is re-written under the requested NAT rule to 220.127.116.11/4444 (18.104.22.168 is assumed to be a private IP address, while 22.214.171.124 is not, in this case).
A media packet from Phone A proceeds outwards through the NAT device unchanged, while a media packet from Phone B, outside the NAT will be addressed to 126.96.36.199/4444, will arrive at the NAT device and be translated to 188.8.131.52/1111, and finally delivered to Phone A inside.
3. Both Phones Outside—Transit Network has NATs
In this case we assume that both phones are somewhere “out there”, and the network with the NAT devices is a transit network—perhaps a long-distance carrier for IP telephones. We assume further that this network is taking part in the processing and routing of INVITE and OK messages. Perhaps this network provides person-location services, as well as media handling.
Let us leave Phone A and Phone B at 184.108.40.206/1111 and 220.127.116.11/2222 respectively.
Assume the INVITE from Phone A arrives at some proxy server in the NAT-equipped transit network under consideration. We may call this the Ingress Proxy Server, because it handles the “inbound” INVITE in our example. The Ingress Proxy Server performs the same “Server Address/Port Discovery” as in the earlier examples, to discover an address that a device inside the transit network could use to reach Phone A. Let us assume that it performs this operation on a specific NAT device, designated NAT A, which is at the egress point from the transit network to Phone A. Say NAT A returns an address/port, which is 10.10.10.10/1010. This is a private address, useful within the transit network, which things inside that transit network could use to reach Phone A. That is, any message packets within the transit network addressed to 10.10.10.10/1010 would be routed by the network to NAT A, which would translate the addresses to 18.104.22.168/1111. and send them on to Phone A.
The INVITE message (now indicating that Phone A wished to receive media at 10.10.10.10/1010) is sent on across the transit network. At some point, another proxy server which we will call the Egress Proxy Server because it will handle the INVITE on the way out of the transit network, will receive this INVITE. This Egress Proxy Server will perform yet another request, on another NAT device (say, NAT B) well situated to provide traffic to and from Phone B, to discover an address by which things “outside” NAT B may reach the end point currently contained in the INVITE—10.10.10.10/1010. NAT B should respond with some address, say 22.214.171.124/2020. The point of this address is that packets sent by things outside (say, for example, Phone B) addressed to 126.96.36.199/2020, arriving at NAT B, will be re-addressed, specifically, translated to be addressed to 10.10.10.10/1010. Then the transit network will route this data (because it's set up to route this way) to NAT A, which will re-address the data again to 188.8.131.52/1111 as indicated in the previous paragraph.
The INVITE is then sent on to Phone B, which will send media packets to address 184.108.40.206/2020, per the contents of the INVITE. The media packets will travel to address 220.127.116.11, which will, assuming correct network configuration, cause it to arrive at NAT B, where it will be translated to 10.10.10.10/1010, and thence to NAT A. NAT A will translate it to 18.104.22.168/1111, and send it on to Phone A.
Exactly the same set of operations, though resulting in different addresses, will apply to the OK coming back from Phone B, but in the opposite direction. First the Egress Proxy Server will ask NAT B for an address by which things inside the transit network may reach Phone B (at 22.214.171.124/2222). Perhaps NAT B will return the address 126.96.36.199/4040. The OK message will be re-written by the Egress Proxy Server to indicate this, and be sent on to the Ingress Proxy Server. This Proxy Server will ask NAT A for an address by which things outside (say, Phone A) may reach address 188.8.131.52/4040. NAT A might return the address 184.108.40.206/5050. The OK will be re-written again to indicate this, and be sent on to Phone A, which will then send all its media packets to address 220.127.116.11/5050.
The upshot is that Phone B sends its media packets to 18.104.22.168/2020, and Phone A will send its media packets to 22.214.171.124/5050, and all the addresses eventually get translated so that the media packets arrive at the right place at the end of the day. The advantages of doing this are that IP addresses such as 126.96.36.199 and 188.8.131.52 can be forced by applications that the ability to control a NAT and selected to be addresses that belong to the transit network itself, guaranteeing that the packet from the two phones arrive at suitable ingress points to the transit network itself, guaranteeing that the transit network actually handles the media data, and furthermore guaranteeing the ingress point for each media stream. Without this, there is no way the transit network has a priori control over how the media packets get from one of the phones to the other.
It will be readily apparent to those skilled in the art that innumerable variations, modification, applications, and extensions of these embodiments and principles can be made without departing form the principles and spirit of the invention. Accordingly, it is intended that the scope of the invention be only limited as necessitated by the accompanying claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5227778||Apr 5, 1991||Jul 13, 1993||Digital Equipment Corporation||Service name to network address translation in communications network|
|US5732078||Jan 16, 1996||Mar 24, 1998||Bell Communications Research, Inc.||On-demand guaranteed bandwidth service for internet access points using supplemental user-allocatable bandwidth network|
|US5781550||Feb 2, 1996||Jul 14, 1998||Digital Equipment Corporation||Transparent and secure network gateway|
|US5793763||Nov 3, 1995||Aug 11, 1998||Cisco Technology, Inc.||Security system for network address translation systems|
|US5883891||Apr 30, 1996||Mar 16, 1999||Williams; Wyatt||Method and apparatus for increased quality of voice transmission over the internet|
|US6006272||Feb 23, 1998||Dec 21, 1999||Lucent Technologies Inc.||Method for network address translation|
|US6038233||Jul 2, 1997||Mar 14, 2000||Hitachi, Ltd.||Translator for IP networks, network system using the translator, and IP network coupling method therefor|
|US6047325||Aug 24, 1998||Apr 4, 2000||Jain; Lalit||Network device for supporting construction of virtual local area networks on arbitrary local and wide area computer networks|
|US6055236||Mar 17, 1999||Apr 25, 2000||3Com Corporation||Method and system for locating network services with distributed network address translation|
|US6058431||Apr 23, 1998||May 2, 2000||Lucent Technologies Remote Access Business Unit||System and method for network address translation as an external service in the access server of a service provider|
|US6094676||May 30, 1997||Jul 25, 2000||Hilgraeve Incorporated||Method and apparatus for peer-to-peer communication|
|US6128298||Apr 24, 1997||Oct 3, 2000||Nortel Networks Corporation||Internet protocol filter|
|US6128664||Mar 24, 1998||Oct 3, 2000||Fujitsu Limited||Address-translating connection device|
|US6141341||Sep 9, 1998||Oct 31, 2000||Motorola, Inc.||Voice over internet protocol telephone system and method|
|US6141749||Sep 12, 1997||Oct 31, 2000||Lucent Technologies Inc.||Methods and apparatus for a computer network firewall with stateful packet filtering|
|US6581108||Nov 30, 1999||Jun 17, 2003||Lucent Technologies Inc.||Managing multiple private data networks using network and payload address translation|
|US6615357||Jan 29, 1999||Sep 2, 2003||International Business Machines Corporation||System and method for network address translation integration with IP security|
|US6717949 *||Aug 31, 1998||Apr 6, 2004||International Business Machines Corporation||System and method for IP network address translation using selective masquerade|
|US6765920||Oct 29, 1999||Jul 20, 2004||Mitsubishi Materials Corporation||Network address converting apparatus and storage medium|
|US6772210 *||Jul 5, 2000||Aug 3, 2004||Nortel Networks Limited||Method and apparatus for exchanging communications between telephone number based devices in an internet protocol environment|
|US6779035||Mar 6, 2000||Aug 17, 2004||Microsoft Corporation||Application programming interface and generalized network address translator for translation of transport-layer sessions|
|US6832322 *||Jun 16, 2000||Dec 14, 2004||International Business Machines Corporation||System and method for network address translation integration with IP security|
|US7224687||Feb 28, 2002||May 29, 2007||Lucent Technologies Inc.||Method and apparatus for voice over IP network address translation|
|US20050180433||Feb 11, 2005||Aug 18, 2005||Alcatel||Bandwidth controller, network and IP subnetwork management process|
|US20050286538||May 13, 2005||Dec 29, 2005||Alcatel||Method and call server for establishing a bi-directional peer-to-peer communication link|
|US20080101389||Oct 19, 2007||May 1, 2008||Alcatel Lucent||Network address translation (nat) traversal equipment for signal messages conforming to the sip protocol by redundancy of address information|
|USRE38902||May 1, 2002||Nov 29, 2005||Lucent Technologies Inc.||System and method for network address translation as an external service in the access server of a service provider|
|EP1793533A1||Sep 4, 2001||Jun 6, 2007||Alcatel USA Sourcing, L.P.||Method an apparatus for facilitating peer-to-peer application communication|
|JP2000059430A||Title not available|
|JP2000138696A||Title not available|
|JP2000209278A||Title not available|
|JP2000224219A||Title not available|
|JPH1056482A||Title not available|
|JPH11150566A||Title not available|
|1||"Microsoft's Invalidity Contentions Under Patent Rule 3-3 And Document Production Under Patent Rule 3-4" Alcatel USA Resources, Inc., v. Microsoft Corporation, Civil Action No. 6:06-CV-499 (E.D. Tex., Tyler Division, Aug. 7, 2007) 42 pages. Redacted.|
|2||"Microsoft's Invalidity Contentions Under Patent Rule 3-3 And Document Production Under Patent Rule 3-4" Alcatel USA Resources, Inc., v. Microsoft Corporation, Civil Action No. 6:06-CV-499 (E.D. Tex., Tyler Division, Aug. 7, 2007) Appendix A-IETF Negotiated Address Reuse ("[NAR]") 24 pages.|
|3||"Microsoft's Invalidity Contentions Under Patent Rule 3-3 And Document Production Under Patent Rule 3-4" Alcatel USA Resources, Inc., v. Microsoft Corporation, Civil Action No. 6:06-CV-499 (E.D. Tex., Tyler Division, Aug. 7, 2007) Appendix B-UPnP Layer3Forwarding:0.3 Service Template ("[L3F]" 22 pages.|
|4||"Microsoft's Invalidity Contentions Under Patent Rule 3-3 And Document Production Under Patent Rule 3-4" Alcatel USA Resources, Inc., v. Microsoft Corporation, Civil Action No. 6:06-CV-499 (E.D. Tex., Tyler Division, Aug. 7, 2007) Appendix C-IETF IP Network Address Translator Application Programming Interface ("NAT-API") 27 pages.|
|5||"Microsoft's Invalidity Contentions Under Patent Rule 3-3 And Document Production Under Patent Rule 3-4" Alcatel USA Resources, Inc., v. Microsoft Corporation, Civil Action No. 6:06-CV-499 (E.D. Tex., Tyler Division, Aug. 7, 2007) Appendix D-U.S. Pat. No. 6,779,035 B1 32 pages.|
|6||"Microsoft's Invalidity Contentions Under Patent Rule 3-3 And Document Production Under Patent Rule 3-4" Alcatel USA Resources, Inc., v. Microsoft Corporation, Civil Action No. 6:06-CV-499 (E.D. Tex., Tyler Division, Aug. 7, 2007) Appendix A—IETF Negotiated Address Reuse ("[NAR]") 24 pages.|
|7||"Microsoft's Invalidity Contentions Under Patent Rule 3-3 And Document Production Under Patent Rule 3-4" Alcatel USA Resources, Inc., v. Microsoft Corporation, Civil Action No. 6:06-CV-499 (E.D. Tex., Tyler Division, Aug. 7, 2007) Appendix B—UPnP Layer3Forwarding:0.3 Service Template ("[L3F]" 22 pages.|
|8||"Microsoft's Invalidity Contentions Under Patent Rule 3-3 And Document Production Under Patent Rule 3-4" Alcatel USA Resources, Inc., v. Microsoft Corporation, Civil Action No. 6:06-CV-499 (E.D. Tex., Tyler Division, Aug. 7, 2007) Appendix C—IETF IP Network Address Translator Application Programming Interface ("NAT-API") 27 pages.|
|9||"Microsoft's Invalidity Contentions Under Patent Rule 3-3 And Document Production Under Patent Rule 3-4" Alcatel USA Resources, Inc., v. Microsoft Corporation, Civil Action No. 6:06-CV-499 (E.D. Tex., Tyler Division, Aug. 7, 2007) Appendix D—U.S. Pat. No. 6,779,035 B1 32 pages.|
|10||Biggs, B. "A SIP Application Level Gateway for Network Address Translation draft-biggs-sip-nat-00.txt" The Internet Engineering Task Force (IETF), Mar. 2000, 8 pages.|
|11||Borella et al. "Realm Specific IP: Protocol Specification" draft-ietf-nat-rsip-protocol-02.txt, The Internet Engineering Task Force (IETF), Aug. 1999, 27 pages.|
|12||Crocker et al. "Universal Plug and Play Internet Gateway Usage Scenarios" UPnP(TM) Forum, Aug. 19, 2000, 6 pages.|
|13||Crocker et al. "Universal Plug and Play Internet Gateway Usage Scenarios" UPnP™ Forum, Aug. 19, 2000, 6 pages.|
|14||Eun-Sang Lee et al., "An Expanded NAT with Server Connection Ability", IEEE pp. 1391-1394 (1999).|
|15||Iyer et al., Layer3Forwarding:0.3 Service Template For Universal Plug and Play Version 1.0, UPnP(TM) Proposed Service Template, UPnP(TM) Forum, Aug. 5, 2000, 15 pages.|
|16||Iyer et al., Layer3Forwarding:0.3 Service Template For Universal Plug and Play Version 1.0, UPnP™ Proposed Service Template, UPnP™ Forum, Aug. 5, 2000, 15 pages.|
|17||Leech at al. "Socks Protocol Version 5" RFC 1928, The Internet Engineering Task Force (IETF), Mar. 1996, 9 pages.|
|18||Lo J. et al, "IP Host Network Address ( and Port) Translation", URL:http://www.watersprings.org/pub/id/draft-ietf-nat-hnat-00.txt>, Nov. 1998, pp. 1-14.|
|19||Montenegro, G. "Negotiated Address Reuse (NAR)" draft-montenegro-aatn-nar-00.txt The Internet Engineering Task Force (IETF), 1998, 21 pages.|
|20||NAT Working Group, Internet Draft (Informational), P. Srisuresh, Campio Communications, Jul. 2000.|
|21||Network address translation. Retrieved from http:en/wikipedia.org on Nov. 17, 2005. 4 pages.|
|22||Packet-based multimedia communications systems, International Telecommunication Union, Recommendation H.323, Feb. 1998, 117 pages.|
|23||Postel et al. "File Transfer Protocol (FTP)" RFC 959, The Internet Engineering Task Force (IETF), Oct. 1985, 69 pages.|
|24||Rosenberg et al. "Getting SIP through.txt" draft-rosenberg-sip-firewalls-00.txt, The Internet Engineering Task Force (IETF), Feb. 22, 2000, 27 pages.|
|25||Schulzrinne, H. et al., "Internet Telephony: Architecture and Protocols-An IETF Perspective", Computer Networks and ISDN Systems, North Holland Publishing, Amsterdam, NL, vol. 31, No. 3., Feb. 11, 1999, pp. 237-255.|
|26||Schulzrinne, H. et al., "Internet Telephony: Architecture and Protocols—An IETF Perspective", Computer Networks and ISDN Systems, North Holland Publishing, Amsterdam, NL, vol. 31, No. 3., Feb. 11, 1999, pp. 237-255.|
|27||SIP Components. Retrieved from http://www.cisco.com on Nov. 25, 2005 1 page.|
|28||SIP Overview Retrieved from http://www.cs.columbia.edu/sip/overview.html on Nov. 23, 2005. 2 pages.|
|29||Srisuresh et al. "IP Network Address Translator (NAT) Terminology and Considerations" draft-ietf-nat-terminology-01.txt, The Internet Engineering Task Force (IETF), Oct. 1998, 26 pages.|
|30||Srisuresh et al. "IP Network Address Translator Application Programming Interface" draft-ietf-nat-api-00.txt, The Internet Engineering Task Force (IETF), Nov. 1998, 23 pages.|
|31||Srisuresh et al. "The IP Network Address Translator (NAT)" draft-rfced-info-srisuresh-05.txt, The Internet Engineering Task Force (IETF), Feb. 1998, 21 pages.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8356092 *||Sep 9, 2008||Jan 15, 2013||Nokia Siemens Networks Oy||Methods, apparatuses, system, and related computer program product for policy control|
|US20100268763 *||Sep 9, 2008||Oct 21, 2010||Juha Antero Rasanen||Methods, Apparatuses, System, and Related Computer Program Product for Policy Control|
|U.S. Classification||370/401, 370/392, 370/466, 726/3, 370/492|
|International Classification||H04L29/12, H04L12/46, H04L29/08, H04L12/28|
|Cooperative Classification||H04L67/104, H04L29/12509, H04L29/12528, H04L61/2567, H04L61/2575, H04L29/12481, H04L61/2557, H04L29/12009|
|European Classification||H04L29/12A4A8B, H04L29/12A4A7, H04L29/12A, H04L29/08N9P, H04L29/12A4A8D, H04L61/25A7, H04L61/25A8B, H04L61/25A8D|
|Nov 1, 2011||AS||Assignment|
Owner name: ALCATEL-LUCENT USA INC., NEW JERSEY
Free format text: MERGER;ASSIGNOR:ALCATEL USA SOURCING, INC.;REEL/FRAME:027152/0547
Effective date: 20081101
|Nov 8, 2011||AS||Assignment|
Owner name: ALCATEL LUCENT, FRANCE
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ALCATEL-LUCENT USA INC.;REEL/FRAME:027192/0982
Effective date: 20111101
|Nov 9, 2011||AS||Assignment|
Owner name: ALCATEL USA SOURCING, INC., TEXAS
Free format text: CHANGE OF NAME;ASSIGNOR:ALCATEL USA SOURCING, L.P.;REEL/FRAME:027196/0671
Effective date: 20061231
|Mar 27, 2012||CC||Certificate of correction|
|May 1, 2012||RF||Reissue application filed|
Effective date: 20111230
|Jan 30, 2013||AS||Assignment|
Owner name: CREDIT SUISSE AG, NEW YORK
Free format text: SECURITY AGREEMENT;ASSIGNOR:LUCENT, ALCATEL;REEL/FRAME:029821/0001
Effective date: 20130130
Owner name: CREDIT SUISSE AG, NEW YORK
Free format text: SECURITY AGREEMENT;ASSIGNOR:ALCATEL LUCENT;REEL/FRAME:029821/0001
Effective date: 20130130
|Aug 1, 2013||AS||Assignment|
Owner name: ALCATEL USA SOURCING, L.P., TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ARAVOX TECHNOLOGIES, INC.;REEL/FRAME:030921/0917
Effective date: 20021220
Owner name: ARAVOX TECHNOLOGIES, MINNESOTA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOLITOR, ANDREW T.;REEL/FRAME:030921/0670
Effective date: 20001127
|Sep 30, 2014||AS||Assignment|
Owner name: ALCATEL LUCENT, FRANCE
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:033868/0001
Effective date: 20140819