Patent Application
20080080532
The present invention provides a dynamic STUN infrastructure configuration (DSIC) and a DSIC server that use a remote diagnostic facility to remotely instruct a client to perform a STUN discovery to determine the type of NAT that the client is behind. The results of the STUN discovery are processed by the DSIC server to determine how to establish a connection. If the NAT type is suitable for SIP call establishment, the DSIC server generally records the customer configuration in a database. If the NAT type is not suitable for SIP call establishment, the DSIC server instructs the client to send all packets to a session border controller. The SBC will perform consistency checks between IP address and port numbers for both signaling and media, comparing the SIP packet and IP headers. In this manner, an SBC is employed only when required. According to a further aspect of the invention, the remote control allows the DSIC server to perform load balancing among the STUN servers and SBCs employed for NAT traversal. In addition, the STUN discovery routine can be dynamically or periodically refreshed to address infrastructure changes and load balancing.
As shown in
The enterprise associated with LAN 105 may obtain Internet service from an Internet Service Provider (ITSP) or (ISP). The ITSP implements an ITSP LAN 160, as shown in
The DSIC server 185 then instructs the client to begin STUN discovery during step 2, using a selected instance of a STUN server 190, with the IP Address of the STUN server being supplied from a pool, to ensure the load on any instance of server is not overloaded. The STUN discovery request is discussed further below in a section entitled “STUN data collection.” Generally, a STUN discovery consists of sending requests to external STUN servers on the Public Internet. On receipt of a STUN packet, the STUN server 190 copies what it sees as the originating IP address and port number into the payload of its reply. The observed originating IP address and port number are the Port number and IP address of the intervening NAT/Firewall 140.
In one exemplary implementation, when a DSIC client 125 registers with the DSIC Server 185, the client 125 is allocated a primary STUN server 190 and a secondary STUN server 190. The DSIC server 185 can optionally maintain a STUN registration table and add the client 125 to the STUN registration table. For example, the STUN registration table can maintain a maximum of 10,000 clients per STUN server instance. Thus, if the current number of clients exceeds 10,000, a slot is sought in the next available free table. Once a slot has been found, the IP Address of the selected STUN server 190 is returned to the DSIC client 125 for use in subsequent STUN Discovery requests. A ticket is optionally used and stored in a database 210 to enable tracking of the request and identify subsequent responses.
The DSIC client 125 performs STUN discovery during step 3 using the supplied STUN server IP Address, for example, in accordance with RFC 3489. The STUN server discovery completes during step 4, and the STUN server 190 provides the results to the DSIC client 125.
The DSIC client 125 provides the results to the DSIC server 185 during step 5, for example, using SIP as a transport. The DSIC server 185 extracts the payload containing the STUN results and the original request tracking ticket. The STUN results are analyzed to determine if an SBC resource is required, as discussed further below in a section entitled “STUN Analysis.” The DSIC server 185 maintains profile data, registration data, resource allocation and load balancing data in the database 210.
If it is determined during step 6 that the STUN analysis indicates that the NAT profile of the DSIC client 125 requires an SBC resource, the resource is allocated from a pool of SBC resource. In one preferred implementation, the SBC resource is allocated using a load balancing mechanism. The SBC can be allocated from a pool, using a load balancing algorithm that limits the number of assigned clients to a maximum number, such as 1000 clients per pool. The SBC can be allocated from a table in the database 210 representing one resource pool item. DSIC clients 125 are assigned a pool instance where the number of clients does not exceed 1000. If the maximum number for a given SBC resource is exceeded, the next SBC instance in the pool is searched up to the maximum number of pools. The usage can be analyzed along with the percentage of customer profiles requiring SBC resource to help capacity planning.
During step 7, the DSIC server 185 sends the DSIC client 125 a payload containing a profile, and a specified SBC resource to utilize, if required. This data is then used by the DSIC client 125 for subsequent incoming/outgoing SIP sessions. The DSIC techniques described herein should be executed before a SIP trunk registration to enable an adjustment of parameters.
The DSIC server 185 can optionally periodically send notification requests (i.e., a dynamic refresh request) to the DSIC client 125 during step 8, to have the DSIC client again perform the STUN discovery of step 3 and provide updates to the DSIC server 185. In this manner, resources can be adjusted between pools being managed by the DSIC server 185. This mechanism is optionally used to probe and respond to dynamic changes in the environment.
In this manner, if there is a change in the environment, such as a customer changing their NAT, the resources can be reallocated to make effective use and enable additional resources to be made available. The profile of the NAT is available for analysis, to help with capacity planning, and can be used to differentiate between different sectors.
During step 9, a SIP session is initiated by an endpoint 110 in an environment where the STUN discovery indicated that an SBC is required. The SIP interface 130 is configured to use the IP Address/port of the SBC 195, as instructed by the DSIC server 185 via the DISC client 125. A SIP invite message is first sent to the selected SBC 195. The SBC 195 will send a SIP invite message to the ITSP 160 and the SBC 195 will change the signaling and media packets, as required, to enable successful traversal through the NAT 140 to the ITSP 160, to support incoming and outgoing sessions. During step 10, both the signaling and media information go via the SBC 195. Among other functions, the SBC 195 translates the IP Address/Ports between the site system and the ITSP.
In one exemplary scenario, the endpoint 110 can communicate directly with the PBX 120 in the case of a non-SIP phone. When communicating directly with the PBX 120, the PBX 120 converts the media and handles the SIP communication via a trunk interface, in a known manner. If the endpoint 110 is a SIP device, however, the endpoint 110 may still connect via the PBX 120, where the signaling and media are handled and resent via the SIP trunk. It is noted that the SIP signaling information is sent via the PBX 120 and SIP trunk. The media information, however, is sent directly, as per the configuration of the DSIC client 125.
During step 11, a SIP session is initiated by an endpoint 110 in an environment where the STUN discovery indicated that an SBC is not required, and can proceed in a conventional manner.
A STUN request typically specifies the following parameters: response-address, change IP flag and change Port flag. The STUN server 190 will reply to the IP and port number specified in the response-address field. If that field is not present, then the server 190 will send its response to the IP and port number from which the request was received.
If the change IP and change Port flags are not set, the STUN server 190 responds from the IP address and port number that the initial packet was sent to (i.e., the source of the reply matches the destination that the request was sent to). If the change IP flag is set, the server 190 replies from a different IP address. If the change port flag is set, the server replies from a different port number.
The STUN response from the STUN server 190 to the DSIC client 125 contains the following information:
mapped-address—the IP address and port number of the client 125 as seen by the STUN server 190;
changed-address—the IP address that would be the source of reply if the request had the change IP flag set; and
source-address—the IP and port where the STUN response was sent from.
As shown in
The results of the STUN discovery test are passed, for example, as an XML encoded document to the DSIC Server 185 during step 5 for analysis.
The following explanation discusses how the test plan can be executed and the meaning of the data that the DSIC Server 185 will attribute to the results. As previously indicated, four tests (Tests 1 through 4) are performed in the exemplary embodiment to characterize the NAT/Firewall 140.
Initially, Test 1 is run by Sending a STUN request to IP address A with Change IP number and Change port number flags set to “no.” If no reply is received, the client 125 is behind a firewall that is blocking UDP. If a reply is received, Test 2 is executed.
During Test 2, a request is sent with the change IP address and Change port number flags set to “yes.” If a reply is received from Test 2 and the mapped-address in Test 1 matches the address of the PBX 120, the solution knows it is freely reachable from any public internet address (unblocked). If a reply from Test 2 is not received and the mapped-address in Test 1 matches the address of the PBX 120, the PBX 120 knows that it is behind a symmetric firewall (i.e., the address of the PBX 120 is on the open Internet but only packet from destinations that it has sent to can send to it, providing a hole is maintained in the firewall 140). If a reply is received from Test 2 and the mapped-address in Test 1 does not match the address if the PBX 120, the PBX 120 knows it is behind a Full Cone NAT. If a reply from Test 2 is not received and the mapped-address in Test 1 does not match the address of the PBX 120, Test 3 is executed.
During Test 3, the PBX 120 sends a request to the second STUN server 190 with the change IP Number and Change Port number flags set to “no.” If the mapped-address field in Test 3 does not match the mapped address in Test 1, the IP Office is behind a symmetric NAT. If the mapped-address field in Test 3 matches the mapped address in Test 1, the PBX 120 runs Test 4.
During Test 4, the PBX 120 sends a request to the first STUN server 190 with the change IP flag set to “no” and the change port flag set to “yes.” If a response is received, the PBX 120 is behind a Restricted NAT. If no response is received, the PBX is behind a Port restricted NAT.
As previously indicated, the results of the STUN discovery test are passed, for example, as an XML encoded document to the DSIC Server 185 during step 5 for analysis.
While the figures herein show an exemplary sequence of steps, it is also an embodiment of the present invention that the sequence may be varied. Various permutations of the algorithms are contemplated as alternate embodiments of the invention.
System and Article of Manufacture Details
As is known in the art, the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein. The computer readable medium may be a recordable medium (e.g., floppy disks, hard drives, compact disks, or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used. The computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk.
The computer systems and servers described herein each contain a memory that will configure associated processors to implement the methods, steps, and functions disclosed herein. The memories could be distributed or local and the processors could be distributed or singular. The memories could be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices. Moreover, the term “memory” should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by an associated processor. With this definition, information on a network is still within a memory because the associated processor can retrieve the information from the network.
It is to be understood that the embodiments and variations shown and described herein are merely illustrative of the principles of this invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention.
