A system for performing Network address translation, which allows applications to request information concerning address translations to be performed, so that those applications may send useful information to other applications for the purposes of allowing applications to communicate through the NAT device in the absence of statically defined rules for specific channels of communication.

PTO Wrapper PDF
Dossier Espace Google
Patent
   RE43057
Priority
Sep 13 2000
Filed
Dec 09 2005
Issued
Jan 03 2012
Expiry
Sep 13 2020
Inventors
Molitor, A…
Assg.orig
ARAVOX TEC…
Assg.curr
Alcatel Lu…
Entity
Large
Referenced by
1
References
34
Maint.:
EXPIRED
II. An Improved Peer…
III. Sample Peer-to-…
IV. A Voice Communic…
IV. Conclusion and A…
0. 70. A network address translation device for facilitating message packet communication between a first application having an internal address valid in an internal address realm and one or more applications in an external address realm, said internal address realm having available to it at least one address valid for use in the external address realm, comprising:
an address translator for translating addresses included in the headers of message packets incoming to and outgoing from the internal address realm in accordance with translation rules that resolve the incompatibility of the internal and external address realms; and
an address manager for establishing a new translation rule for the address translator in response to a service request received from the first application, the new translation rule including the internal address specified in the service request paired with an external address from the at least one address valid for use in the external address realm.
0. 79. A method for facilitating message packet communication between a first application in an internal address realm and one or more applications in an external address realm, said internal address realm having available to it at least one address valid for use in the external address realm and an address translator translating addresses included in headers of message packets incoming to and outgoing from the internal address realm in accordance with translation rules that map correspondence between addressing in the internal and external address realms, the method comprising the steps of:
sending from the first application a service request for establishing a new translation rule at the address translator, the service request specifying an internal address of the first application to be mapped with an external address for the first application from the at least one address valid for use in the external address realm; and
receiving the external address at the first application.
1. A network address translation device for facilitating message packet communication between a first application having an internal address valid in an internal address realm and one or more applications in an external address realm, said internal address realm having available to it a set of available addresses valid for use in the external address realm, comprising:
an address translator for translating addresses included in the headers of message packets incoming to and outgoing from the internal address realm in accordance with translation rules that resolve the incompatibility of the internal and external address realms;
an address manager for establishing and storing the translation rules, said address manager having access to the set of available addresses valid for use in the external address realm; and
a control channel communicating with the address manager for receiving from the first application a service request message for establishing in response to the first application's service request a translation rule specified by the first application.
0. 53. A method for facilitating message packet communication between an internal address realm and an external address realm, comprising:
receiving at a network address translation device a service request from a first application having an internal address valid in the internal address realm, wherein the network address translation device has an address translator for translating addresses included in the headers of message packets incoming to and outgoing from the internal address realm in accordance with at least one translation rule that maps correspondence between addressing in the internal and external address realms;
establishing at the network address translation device a translation rule with respect to the service request from the first application, the translation rule including an external address valid for use in the external address realm and paired with the first application's internal address to use in an outgoing message to facilitate an incoming message from an application in the external address realm; and
providing the external address to the first application.
14. A method for facilitating message packet communication between a first application having an internal address valid in an internal address realm and one or more applications in an external address realm, said internal address realm having available to it a set of addresses valid for use in the external address realm, comprising:
providing the internal address realm with receiving message packets at a network address translation device having an address translator for translating addresses included in the headers of message packets incoming to and outgoing from the internal address realm in accordance with translation rules that resolve the incompatibility of the internal and external address realms;
providing establishing and storing using an address manager for establishing and storing the translation rules for the network address translation device, said address manager having access to the set of available addresses valid for use in the external address realm; and
providing receiving via a control channel communicating with the address manager for receiving from the first application a service request message transmitted from the first application for establishing in response to the first application's service request a translation rule specified by the first application.
0. 101. An apparatus for facilitating message packet communication between a first application in an internal address realm and one or more applications in an external address realm, said internal address realm having available to it at least one address valid for use in the external address realm, comprising:
a message component for sending message packets from the first application to an address translator for translating addresses included in headers of message packets incoming to and outgoing from the internal address realm in accordance with translation rules that map correspondence between addressing in the internal and external address realms; and
a service component for (a) sending from the first application to an address manager for the internal address realm a service request for establishing a new translation rule at the address translator, the service request specifying an internal address of the first application to be mapped with an external address from the at least one address valid for use in the external address realm, and (b) for receiving an address manager response comprising the external address mapped to the internal address of the first application.
0. 43. A method for facilitating message packet communication between a first application having an internal address valid in an internal address realm and one or more applications in an external address realm, said internal address realm having available to it a set of addresses valid for use in the external address realm, comprising:
receiving a service request from the first application at a network address translation device, wherein the network address translation device has an address translator for translating addresses included in the headers of message packets incoming to and outgoing from the internal address realm in accordance with at least one translation rule that maps correspondence between addressing in the internal and external address realms; and
responsive to the service request from the first application received by the network address translation device, establishing a translation rule specified by the service request that provides for the first application an external address realm address paired with the first application's internal address to use in an outgoing message to facilitate an incoming message from an application in the external address realm.
0. 62. A first application encoded on a non-transitory computer readable medium for facilitating message packet communication between a first host having an internal address valid in an internal address realm and one or more hosts in an external address realm, the internal address realm having available to it a set of addresses valid for use in the external address realm, the first application comprising software instructions executable by a processor for performing steps comprising:
transmitting in the internal address realm to a network address translator a service request whereby a translation rule is established for the network translator, the network translator adapted to translate addresses included in headers of message packets incoming to and outgoing from the internal address realm in accordance with translation rules that resolve incompatibility between the internal and external address realms;
receiving in the internal address realm from the network translator in response to the service request a first address valid for use in the external address realm; and
causing the first address to be transmitted to the external address realm in an IP packet sent by the first application.
0. 35. A method for facilitating message packet communication between a first host having an internal address valid in an internal address realm and one or more hosts in an external address realm, the internal address realm having available to it a set of addresses valid for use in the external address realm, comprising the steps of:
transmitting from an initiating application associated with the first host in the internal address realm to a network address translation device a service request establishing a translation rule on the network translation device, the network translation device adapted to translate addresses included in headers of message packets incoming to and outgoing from the internal address realm in accordance with translation rules that resolve incompatibility between the internal and external address realms;
receiving at the initiating application from the network translation device in response to the service request a first address valid for use by the initiating application to identify itself in the external address realm; and
causing the first address to be transmitted to the external address realm in a data portion of an sip message from the initiating application.
0. 93. A method for facilitating message packet communication between a first application having an internal address valid in an internal address realm and one or more applications in an external address realm, using a network address translator that translates addresses included in the headers of message packets incoming to and outgoing from the internal address realm in accordance with at least one address translation rule that resolves incompatibility of the addressing schemes of the internal and external address realms, comprising the method steps:
receiving from the first application a service message requesting establishment of an address translation rule;
using an address manager associated with the address translator to establish an address translation rule accessible to the address translator, said rule providing an external address and port for use by the first application as a terminating address identifying a device and port that will receive inbound message packets directed to the first application during peer-to-peer communication; and
communicating to the first application the external address established in the address translation rule for use by the first application as its terminating address in a data portion of a peer-to-peer communication.
0. 97. A method for facilitating message packet communication between a first application having an internal address valid in an internal address realm and one or more applications in an external address realm, using a network address translator that translates addresses included in the headers of message packets incoming to and outgoing from the internal address realm in accordance with at least one address translation rule that resolves incompatibility of the addressing schemes of the internal and external address realms, comprising the method steps:
receiving from the first application a service message requesting establishment of an address translation rule;
using an address manager associated with the address translator to establish an address translation rule accessible to the address translator, said rule providing an external address and port for use by the first application as an originating address identifying a device and port that will receive inbound message packets directed to the first application during peer-to-peer communication; and
communicating to the first application the external address established in the address translation rule for use by the first application as its originating address in a data portion of a peer-to-peer communication.
0. 27. A method for facilitating message packet communication between a first application having an internal address valid in an internal address realm and one or more applications in an external address realm, said internal address realm having available to it a set of addresses valid for use in the external address realm, comprising:
receiving message packets at a network address translation device having an address translator for translating addresses included in the headers of message packets incoming to and outgoing from the internal address realm in accordance with translation rules that resolve the incompatibility of the internal and external address realms;
establishing and storing using an address manager the translation rules for the network address translation device, said address manager having access to the set of available addresses valid for use in the external address realm; and
receiving via a control channel communicating with the address manager a service request message transmitted from the first application for establishing in response a translation rule specified by the first application,
wherein the address manager transmits to the first application in response to the service request a first address valid for use in the external address realm and wherein the first application causes the first address to be transmitted to the external address realm in an sip message.
0. 91. A method for facilitating message packet communication between an internal application in an internal address realm and an external application in an external address realm, said internal address realm having available to it at least one address valid for use in the external address realm and an address translator translating addresses included in headers of message packets incoming to and outgoing from the internal address realm in accordance with translation rules that map correspondence between addressing in the internal and external address realms, the method comprising the steps of:
specifying, by the internal application, establishment of a first translation rule at the address translator, the first translation rule defining a first internal address for the internal application to be mapped with a first external address from the at least one address valid for use in the external address realm; and
sending, from the internal application, an outgoing message whose header includes the first internal address to the external application via the address translator;
whereby the first internal address included in the header of the outgoing message is translated according to the first translation rule into the first external address and this translated outgoing message initiates communications with the external application, and in response to such internal application initiated communications, the external application in the external address realm sends an incoming message addressed to the first external address which the address translator will translate according to the first translation rule into the first internal address for the internal application.
2. The network address translation device of claim 1, wherein the first application specifies that the translation rule to be established associates the first application's internal address with an available external address and the first application has access to the associated available external address as data for an outgoing message packet.
3. The network address translation device of claim 1 wherein the first application specifies that the translation rule to be established associates the first application's internal address with an available external address that is a particular WP address or within a specified range of IP addresses.
4. The network address translation device of claim 1 wherein the first application specifies that the translation rule is one of two or more translation rules applicable to an incoming message packet, where the selection of which translation rule is applied is contingent on address information in the incoming message packet.
5. The network address translation device of claim 2 wherein the available external address requested by the first application is a terminating address.
6. The network address translation device of claim 2 wherein the available external address requested by the first application is an originating address.
7. The network address translation device of claim 2 wherein the internal address realm is a private network and the external address realm is the Internet.
8. The network address translation device of claim 1 wherein the internal address realm is a private network and the external address realm is the Internet and the address manager establishes a translation rule by associating an address valid in the private network realm with an address valid in the Internet.
9. The network address translation device of claim 4, wherein the selection of which translation rule is applied is made in response to the presence or absence of specified originating address information in the incoming message.
10. The network address translation device of claim 1, wherein the communication facilitated is peer-to-peer application communication.
11. The network address translation device of claim 1, wherein the communication facilitated is peer-to-peer telephony communication.
12. The network address translation device of claim 3, wherein the translation rule to be established forces the outgoing message packet to have a destination address in a transit network.
13. The network address translation device of claim 3, wherein the translation rule to be established forces at least a portion of the packet communication between the first application and the second application to pass through a specified network.
15. The method of claim 14, wherein the step of providing receiving via a control channel comprises receiving from the first application a request that specifies specifying that the translation rule to be established associates the first application's internal address with an available external address and providing returning to the first application access to the associated available external address as data for an outgoing message packet.
16. The method of claim 14 wherein the step of providing receiving via a control channel for receiving a request comprises receiving from the first application a request that specifies specifying that the translation rule to be established associates the first application's internal address with an available external address that is a particular IP address or within a specified range of IP addresses.
17. The method of claim 14 wherein the step of providing receiving via a control channel for receiving a request comprises receiving from the first application a request that the translation rule is one of two or more translation rules applicable to an incoming message packet, where the selection of which translation rule is applied is contingent on address information in the incoming message packet.
18. The method of claim 14 wherein the step of providing receiving via a control channel for receiving a request comprises receiving from the first application a request for a translation rule for a terminating address.
19. The method of claim 14 wherein the step of providing receiving via a control channel for receiving a request comprises receiving from the first application a request for a translation rule for an originating address.
20. The method of claim 14 wherein the internal address realm is a private network and the step of providing establishing and storing translation rules using an address manager comprises providing using an address manager having access to a set of available addresses valid in the Internet.
21. The method of claim 14 wherein the internal address realm is a private network and the external address realm is the Internet and the step of providing establishing and storing the translation rules using an address manager comprises providing using an address manager that establishes a translation rule by associating an address valid in the private network realm with an address valid in the Internet.
22. The method of claim 17, wherein step of providing receiving via a control channel for receiving a request comprises receiving from the first application a request that the translation rule is one of two or more translation rules applicable to an incoming message, where the selection of which translation rule is applied is made in response to the presence or absence of specified originating address information in the incoming message.
23. The method of claim 14, wherein the communication facilitated is peer-to-peer application communication.
24. The method of claim 14, wherein the communication facilitated is peer-to-peer telephony communication.
25. The method of claim 16, wherein the step of providing receiving via a control channel for receiving a request comprises receiving from the first application a request that the translation rule to be established forces the outgoing message packet to have a destination address in a transit network.
26. The method of claim 16, wherein the step of providing receiving via a control channel for receiving a request comprises receiving from the first application a request that the translation rule to be established forces at least a portion of the packet communication between the first application and the second application to pass through a specified network.
0. 28. The method of claim 27, wherein the sip message is an sip INVITE message.
0. 29. The method of claim 27, wherein the first application causes the sip message to be transmitted to a second application in the external address realm.
0. 30. The method of claim 27, wherein the first address includes an IP address and a port number.
0. 31. The method of claim 27, wherein an sip proxy server is invoked in transmitting the sip message to a second application in the external address realm.
0. 32. The method of claim 27, wherein the sip message is used to establish a peer-to-peer communication session.
0. 33. The method of claim 27, wherein the sip message is used to establish an IP telephonic communication session.
0. 34. The method of claim 27, wherein the sip message is used to establish an instant messaging session.
0. 36. The method of claim 35, wherein the sip message is an sip INVITE message.
0. 37. The method of claim 35, wherein the first address is transmitted to an sip-aware application in the external address realm.
0. 38. The method of claim 35, wherein the first address includes an IP address and a port number.
0. 39. The method of claim 35, wherein an sip proxy server is invoked in transmitting the first address to an sip-aware application in the external address realm.
0. 40. The method of claim 35, wherein the sip message is used to establish a peer-to-peer communication session.
0. 41. The method of claim 35, wherein the sip message is used to establish an IP telephonic communication session.
0. 42. The method of claim 35, wherein the sip message is used to establish an instant messaging session.
0. 44. The method of claim 43, wherein the service request comprises instructing the network address translation device to communicate the external address realm address included in the translation rule to the first application.
0. 45. The method of claim 43, further comprising receiving a service request with specifications for a new translation rule.
0. 46. The method of claim 43, further comprising receiving a service request with desired characteristics for a translation rule.
0. 47. The method of claim 46, wherein the desired characteristics for the translation rule identify a specified range of IP addresses.
0. 48. The method of claim 46, wherein the desired characteristics for the translation rule identify a particular external IP address.
0. 49. The method of claim 43, wherein the message packet communication is communication of media packets.
0. 50. The method of claim 43, wherein the message packet communication is communication of digitized voice packets.
0. 51. The method of claim 43, further comprising establishing a translation rule with different translated address values depending on an incoming source address.
0. 52. The method of claim 43, wherein the step of receiving a service request comprises receiving a request communicated from a proxy server.
0. 54. The method of claim 53, further comprising receiving a service request with specifications for a new translation rule.
0. 55. The method of claim 53, further comprising receiving a service request with desired characteristics for a translation rule.
0. 56. The method of claim 55, wherein the desired characteristics for the translation rule identify a specified range of IP addresses.
0. 57. The method of claim 55, wherein the desired characteristics for the translation rule identify a particular external IP address.
0. 58. The method of claim 53, wherein the message packet communication is communication of media packets.
0. 59. The method of claim 53, wherein the message packet communication is communication of digitized voice packets.
0. 60. The method of claim 53, wherein the step of establishing at the network address translation device a translation rule comprises establishing a translation rule with different translated address values depending on an incoming source address.
0. 61. The method of claim 52, wherein the step of receiving at a network address translation device a service request comprises receiving a request communicated from a proxy server.
0. 63. The first application of claim 62, wherein the application is sip-aware and the IP packet is an sip INVITE message.
0. 64. The first, sip-aware application of claim 63, wherein the sip message is transmitted to a second sip-aware application in the external address realm.
0. 65. The first application of claim 62, wherein the first address includes an IP address and a port number.
0. 66. The first sip-aware application of claim 63, wherein an sip proxy server is invoked in transmitting the first address to a second sip-aware application in the external address realm.
0. 67. The first application of claim 62, wherein the IP packet is used to establish a peer-to-peer communication session.
0. 68. The first application of claim 62, wherein the IP packet is used to establish an IP telephonic communication session.
0. 69. The first application of claim 62, wherein the IP packet is used to establish an instant messaging session.
0. 71. The device of claim 70 wherein the service request specifies a required or desired characteristic for the external address to be established in the new translation rule.
0. 72. The device of claim 71, wherein the required or desired characteristic is that the external address of the new translation rule must be a particular address or in a specified range of IP addresses.
0. 73. The device of claim 71, wherein the required or desired characteristic for the external address is an externally valid port number to be translated into an internally valid port number.
0. 74. The device of claim 73, wherein the internally valid port number is of one value or a different value depending on an incoming source address.
0. 75. The device of claim 73, wherein the external address includes an externally valid IP address and the externally valid port number, which the address translator will translate into an internally valid IP address and the internally valid port number of the internal address for the first application.
0. 76. The device of claim 70, wherein the address manager comprises a processor and memory for storing code that determines what services and functions are available in response to control messages from the application.
0. 77. The device of claim 76, comprising a control channel whereby the address manager exchanges the control messages with the application.
0. 78. The device of claim 77, wherein the address manager receives service requests and returns requested information or status information to the application over the control channel.
0. 80. The method of claim 79 wherein the service request specifies a required or desired characteristic for the external address to be established in the new translation rule.
0. 81. The method of claim 80, wherein the required or desired characteristic is that the external address of the new translation rule must be a particular address or in a specified range of IP addresses.
0. 82. The method of claim 80, wherein the required or desired characteristic for the external address is an externally valid port number to be translated into an internally valid port number.
0. 83. The method of claim 82, wherein the internally valid port number is of one value or a different value depending on an incoming source address.
0. 84. The method of claim 82, wherein the external address includes an externally valid IP address and the externally valid port number, which the address translator will translate into an internally valid IP address and the internally valid port number of the internal address for the first application.
0. 85. The method of claim 79, wherein the first application sends service requests and receives requested information or status information from the address translator over a control channel.
0. 86. The method of claim 79, comprising the step of providing, in a data portion of a message from the first application, the external address to which messages from the one or more applications in the external address realm are to be sent for communicating with the first application.
0. 87. The method of claim 86, wherein the one or more applications in the external address realm can initiate communications with the first application by addressing messages to the external address.
0. 88. The method of claim 79, comprising the step of providing, in a data portion of a message from the first application, the external address to a second application acting as a proxy on behalf of the one or more applications in the external address realm.
0. 89. The method of claim 79, wherein the first application and the one or more applications in the external address realm are peer-to-peer applications which communicate in an essentially symmetric fashion.
0. 90. The method of claim 89, wherein each peer-to-peer application functions as a client and a server.
0. 92. The method of claim 91, comprising the steps of:
specifying, by the internal application, establishment of a second translation rule at the address translator, the second translation rule defining a second internal address for the internal application to be mapped with a second external address from the at least one address valid for use in the external address realm; and
providing, in a data portion of a message from the internal application, the second external address to the external application in the external address realm;
whereby the external application can initiate communications with the internal application by addressing messages to the second external address which the address translator will translate according to the second translation rule into the second internal address for the internal application.
0. 94. The method of claim 93 wherein the address translation rule established is formulated so that the address translator checks a source address and/or port of an incoming message and applies a different translation rule depending on the source address and/or port of an incoming message.
0. 95. The method of claim 93 wherein the service message specifies that the requested address translation rule establish a particular terminating address from those external addresses available to the first application.
0. 96. The method of claim 93 wherein the service message specifies that the requested address translation rule establish a terminating address from within a specified range of external addresses available to the first application.
0. 98. The method of claim 97 wherein the address translation rule established is formulated so that the address translator checks the source address and/or port of an incoming message and applies a different translation rule depending on the source address and/or port of an incoming message.
0. 99. The method of claim 97 wherein the service message specifies that the requested address translation rule establish a particular originating address from those external addresses available to the first application.
0. 100. The method of claim 97 wherein the service message specifies that the requested address translation rule establish an originating address from within a specified range of external addresses available to the first application.
0. 102. The apparatus of claim 101 wherein the service request specifies a required or desired characteristic for the external address to be established in the new translation rule.
0. 103. The apparatus of claim 102, wherein the required or desired characteristic is that the external address of the new translation rule must be a particular address or in a specified range of IP addresses.
0. 104. The apparatus of claim 102, wherein the required or desired characteristic for the external address is an externally valid port number to be translated into an internally valid port number.
0. 105. The apparatus of claim 104, wherein the internally valid port number is of one value or a different value depending on an incoming source address.
0. 106. The apparatus of claim 104, wherein the external address includes an externally valid IP address and the externally valid port number, which the address translator will translate into an internally valid IP address and the internally valid port number of the internal address for the first application.
0. 107. The apparatus of claim 101, further comprising a component for providing, in a data portion of a message from the first application, the external address.
0. 108. The apparatus of claim 101, wherein the first application and the one or more applications in the external address realm are peer-to-peer applications which communicate in an essentially symmetric fashion.
0. 109. The apparatus of claim 101, wherein the address manager response includes the external address for use by the first application.
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.

II. An Improved Peer-to-peer Network Address Translation Device

The following discussion makes reference to FIG. 3 to describe how the present invention uses an improved NAT device and method to establish peer-to-peer Internet communications.

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.

FIG. 3 shows a system for facilitating improved communication between two peer applications in different address realms. Host A 110 and Host B 310 are both part of address realm 100. Host A has one or more applications running in it. By way of example, Application A1 121 and Application A2 122 are shown. Each has an internally valid terminating address and internally valid originating address. Host B may also have one or more applications running in it. By way of example, Application B1 321 and Application B2 322 are shown. Host A and Host B may be on the same network or otherwise connected so that there is a channel 370 (e.g., connection to a common communication network) for communication between Host A and Host B. Additional hosts may also be present in this address realm 100 but are not shown.

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 FIG. 2. The other is the address manager section 324. An IP message channel 360 connects Host A 110 to the address translation section. This channel 360 is used when an application on Host A or any other host served by NAT 320 needs to send out an outgoing message and requires internally valid addresses translated into externally valid addresses. The channel 360 is also used when an incoming message has arrived with an externally valid address, the NAT 320 has translated the externally valid addresses in an incoming message into internally valid addresses and needs to send on the message to the appropriate application in address realm 100.

The address translation section 322 is connected to the “outside” address realms. By way of example, FIG. 3 shows a Global Internet realm 400 connected to address translation section 322. Within address realm 400 is another address realm 200 containing Host R 410 and Host S 510 that may host other applications (Applications R1, R2, S1 and S2 are shown by way of example) with which Host A or Host B may communicate. Channel 470 (e.g., a common network connection) provides communication between Host R 410 and Host S 510.

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.

III. Sample Peer-to-Peer Interchanges Using the Control Channel

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 FIG. 3.

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:

    • 1. Application A1 121 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 A1 is using;
    • 2. Application A1 121 receives from the address manager 324 in return an externally valid IP address and a port number which the NAT device 320 will translate to the internally valid terminating address provided by Application A1 in its request.
    • 3. Application A1 (which we must assume has the ability to address an IP message packet to Host R, Application R1 421) then sends an IP message packet via the address translation section 322 of NAT 320. The data portion of the packet contains the externally valid IP address and a port number to inform Host R 410, Application R1 421 how to send packets to Application A1.
    • 4. Application R1 421 at Host R 410 sends a connection request per the externally valid IP address and a port number Application A1 gave it, which (being correctly addressed to an official IP address) arrives at the NAT 320, where the externally valid address is translated to Application A1's internally valid address and port.
    • 5. NAT 320 sends the reply packet from Application R1 421 on to Application A1 121 on Host A.
      Client Address/Port Allocation and Discovery Example:

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:

    • 1. Application R1 421 sends a packet to Host A requiring from Host A, Application A1 121, information about from which IP address and port the connection from Application A1 121 will originate. This originating address information is useful for security and may be required by Application R1 for its own purposes, such as compliance with a communication protocol.
    • 2. Application A1 121 on Host A 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 A1 will use to communicate with the micro-server on Host R.
    • 3. Application A1 121 receives from the address manager 324 in return an externally valid IP address and a port number into which the NAT device 320 will translate the internally valid originating address provided by Application A1 in its request.
    • 4. Application A1 121 (which we must assume has the ability to address an IP message packet to Host R, Application R1) then sends an IP message packet via the address translation section 322 of NAT 320. The data portion of the packet contains the externally valid IP address and a port number to inform Host R, Application R1 421 from what IP address and port packets from Application A1 121 will originate.
    • 5. Application A1 121 then initiates the connection by sending an outgoing packet addressed to Host R, Application R1 421, which packet arrives at the address translation section 322 of NAT device 320.
    • 6. The address translation section 322 of NAT device 320 translates the packet's source address and port (which indicate Application A1's internal IP address and port) to the externally valid version of these (which was passed to Application A1 in step 3 and which Application A1 sent to Application R1 in step 4).
    • 7. The address translation section 322 sends the packet on to Host R, Application R1 with the source information Application R1 now expects.
      Server Address/Port Alocation and Discovery with Separate Requestor/Server Example:

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:

    • 1. Application A1 121 communicates with Application B1 over channel 370 to discover what internally valid address and port can be used to contact Application B1 321.
    • 2. Application A1 121 needs to contact Application R1 in address realm 200 to provide Application R1 externally valid address information for Application B1.

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;

    • 3. Application A1 121 receives from the address manager 324 in return an externally valid IP address and a port number which the NAT device 320 will translate to the internally valid terminating address for Application B1 provided by Application A1 in its request.
    • 4. Application A1 121 (which we must assume has the ability to address an IP message packet to Host R, Application R1 421) then sends an IP message packet via the address translation section 322 of NAT 320. The data portion of the packet contains the externally valid IP address and a port number to inform Host R, Application R1 421, how to send packets to Application B1 321.
    • 5. Application R1 421 at Host R sends a connection request per the externally valid IP address and a port number Application A1 121 gave it, which (being correctly addressed to an official IP address) arrives at the NAT 320, where the externally valid address is translated to Application B1's internally valid address and port.
    • 6. NAT 320 sends the reply from Application R1 on to Application B1 on Host B.
      Client Address/Port Allocation and Discovery With Client/Servers Separated From Negotiating Entities Example:

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:

    • 1. Application R1 421 sends a packet to Host A 110 requiring from Host A, Application A1 121 information about from which IP address and port the connection with Application B1 321 will originate. This originating address information is useful for security and may be required by Application S1 for its own purposes, such as compliance with a communication protocol
    • 2. Application A1 121 communicates with Application B1 321 over channel 370 to discover what internally valid address and port will be used by Application B1 321 to contact Application S1 521.
    • 3. Application A1 121 on Host A 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 will use to communicate with the micro-server on Host S 510.
    • 4. Application A1 121 receives in return from the address manager 324 an externally valid IP address and a port number into which the NAT device 320 will translate the internally valid originating address provided by Application A1 121 in its request.
    • 5. Application A1 121 (which we must assume has the ability to address an IP message packet to Host R, Application R1 421) then sends an IP message packet via the address translation section 322 of NAT 320. The data portion of the packet contains the externally valid IP address and a port number to inform Host R, Application R1 421 from what IP address and port packets from Application B1 321 will originate.
    • 6. Application R1 421 will communicate with Application S1 521 via communication channel 470 to communicate to Application S1 521 the IP address and port Application B1 321 will use to communicate to Application S1 521.

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.

    • 8. The address translation section 322 of NAT device 320 translates the packet's source address and port (which indicate Application B1's internal IP address and port) to the externally valid version of these (which was passed to Application A1 121 in step 4 and which Application A1 sent to Application R1 421 in step 5.
    • 9. The address translation section 322 sends the packet via Host R 410 on to Host S, Application S1 521 with the source information Application S1 now expects.

IV. A Voice Communication Application

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 1.1.1.1, 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 2.2.2.2, port number 2222.

Phone B may begin to send media packets with digitized voice to 1.1.1.1/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 2.2.2.2/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 FIG. 3.

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, 2.2.2.2/2222, into this OK message. In this case, 2.2.2.2 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 3.3.3.3/3333, by which devices on the other side (the “outside”) of the NAT device may reach a device at 2.2.2.2/2222 (the target phone). The proxy server re-writes the OK message to indicate 3.3.3.3/3333 instead of 2.2.2.2/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 1.1.1.1/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 3.3.3.3/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 2.2.2.2/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 1.1.1.1/1111 address is re-written under the requested NAT rule to 4.4.4.4/4444 (1.1.1.1 is assumed to be a private IP address, while 4.4.4.4 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 4.4.4.4/4444, will arrive at the NAT device and be translated to 1.1.1.1/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 1.1.1.1/1111 and 2.2.2.2/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 1.1.1.1/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 20.20.20.20/2020. The point of this address is that packets sent by things outside (say, for example, Phone B) addressed to 20.20.20.20/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 1.1.1.1/1111 as indicated in the previous paragraph.

The INVITE is then sent on to Phone B, which will send media packets to address 20.20.20.20/2020, per the contents of the INVITE. The media packets will travel to address 20.20.20.20, 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 1.1.1.1/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 2.2.2.2/2222). Perhaps NAT B will return the address 40.40.40.40/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 40.40.40.40/4040. NAT A might return the address 50.50.50.50/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 50.50.50.50/5050.

The upshot is that Phone B sends its media packets to 20.20.20.20/2020, and Phone A will send its media packets to 50.50.50.50/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 20.20.20.20 and 50.50.50.50 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.

IV. Conclusion and Aternate Embodiments

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.

INVENTORS:

Molitor, Andrew T.

THIS PATENT IS REFERENCED BY THESE PATENTS:
Patent Priority Assignee Title
8356092, Oct 08 2007 NOKIA SOLUTIONS AND NETWORKS OY Methods, apparatuses, system, and related computer program product for policy control
THIS PATENT REFERENCES THESE PATENTS:
Patent Priority Assignee Title
5227778, Apr 05 1991 ENTERASYS NETWORKS, INC Service name to network address translation in communications network
5732078, Jan 16 1996 HANGER SOLUTIONS, LLC On-demand guaranteed bandwidth service for internet access points using supplemental user-allocatable bandwidth network
5781550, Feb 02 1996 Hewlett Packard Enterprise Development LP Transparent and secure network gateway
5793763, Nov 03 1995 Cisco Technology, Inc Security system for network address translation systems
5883891, Apr 30 1996 ICALL, INC DOING BUSINESS AS MAILSIGNAL Method and apparatus for increased quality of voice transmission over the internet
6006272, Feb 23 1998 WSOU Investments, LLC Method for network address translation
6038233, Jul 04 1996 Hitachi, Ltd. Translator for IP networks, network system using the translator, and IP network coupling method therefor
6047325, Oct 24 1997 Network device for supporting construction of virtual local area networks on arbitrary local and wide area computer networks
6055236, Mar 05 1998 Hewlett Packard Enterprise Development LP Method and system for locating network services with distributed network address translation
6058431, Apr 23 1998 ASCEND COMMUNICATIONS, INC System and method for network address translation as an external service in the access server of a service provider
6094676, May 30 1997 TAINOAPP, INC Method and apparatus for peer-to-peer communication
6128298, Apr 26 1996 RPX CLEARINGHOUSE LLC Internet protocol filter
6128664, Oct 20 1997 Fujitsu Limited Address-translating connection device
6141341, Sep 09 1998 Google Technology Holdings LLC Voice over internet protocol telephone system and method
6141749, Sep 12 1997 Alcatel Lucent Methods and apparatus for a computer network firewall with stateful packet filtering
6581108, Nov 30 1999 Lucent Technologies Inc Managing multiple private data networks using network and payload address translation
6615357, Jan 29 1999 International Business Machines Corporation System and method for network address translation integration with IP security
6717949, Aug 31 1998 International Business Machines Corporation System and method for IP network address translation using selective masquerade
6765920, Oct 29 1998 Mitsubishi Materials Corporation Network address converting apparatus and storage medium
6772210, Jul 05 2000 Genband US LLC; SILICON VALLEY BANK, AS ADMINISTRATIVE AGENT Method and apparatus for exchanging communications between telephone number based devices in an internet protocol environment
6779035, Mar 06 2000 Microsoft Technology Licensing, LLC Application programming interface and generalized network address translator for translation of transport-layer sessions
6832322, Jan 29 1999 International Business Machines Corporation System and method for network address translation integration with IP security
7224687, Feb 28 2002 WSOU Investments, LLC Method and apparatus for voice over IP network address translation
20050180433,
20050286538,
20080101389,
EP1793533,
JP10056482,
JP11150566,
JP2000059430,
JP2000138696,
JP2000209278,
JP2000224219,
RE38902, Apr 23 1998 Lucent Technologies Inc. System and method for network address translation as an external service in the access server of a service provider
ASSIGNMENT RECORDS    Assignment records on the USPTO
////////
Executed onAssignorAssigneeConveyanceFrameReelDoc
Nov 27 2000MOLITOR, ANDREW T ARAVOX TECHNOLOGIESASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS 0309210670 pdf
Dec 20 2002ARAVOX TECHNOLOGIES, INC ALCATEL USA SOURCING, L P ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS 0309210917 pdf
Dec 09 2005Alcatel Lucent(assignment on the face of the patent)
Dec 31 2006ALCATEL USA SOURCING, L P Alcatel USA Sourcing, IncCHANGE OF NAME SEE DOCUMENT FOR DETAILS 0271960671 pdf
Nov 01 2008Alcatel USA Sourcing, IncAlcatel-Lucent USA IncMERGER SEE DOCUMENT FOR DETAILS 0271520547 pdf
Nov 01 2011Alcatel-Lucent USA IncAlcatel LucentASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS 0271920982 pdf
Jan 30 2013Alcatel LucentCREDIT SUISSE AGSECURITY AGREEMENT0298210001 pdf
Aug 19 2014CREDIT SUISSE AGAlcatel LucentRELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS 0338680001 pdf
MAINTENANCE FEES AND DATES:    Maintenance records on the USPTO
Date Maintenance Fee Events
Nov 18 2011ASPN: Payor Number Assigned.


Date Maintenance Schedule
Jan 03 20154 years fee payment window open
Jul 03 20156 months grace period start (w surcharge)
Jan 03 2016patent expiry (for year 4)
Jan 03 20182 years to revive unintentionally abandoned end. (for year 4)
Jan 03 20198 years fee payment window open
Jul 03 20196 months grace period start (w surcharge)
Jan 03 2020patent expiry (for year 8)
Jan 03 20222 years to revive unintentionally abandoned end. (for year 8)
Jan 03 202312 years fee payment window open
Jul 03 20236 months grace period start (w surcharge)
Jan 03 2024patent expiry (for year 12)
Jan 03 20262 years to revive unintentionally abandoned end. (for year 12)