The invention is related to the field of telecommunication networks and their operation and more specifically, the invention is directed to a method and apparatus (system) for executing name address translation and other types of information retrieval request operations in a packet-based telecommunications network.
Networked computers not only represented an advancement in the area of communications, but also introduced challenges in processing power and speed that was not critical to stand alone devices. For example, when a first computer on a network needed to connect to a second computer, a look-up operation had to be performed in the first computer's memory to determine the physical addresses of the second computer and then proceed with a desired networking operation. As networks grew in size and complexity, it was necessary to create and locally store “networking” files for associating a machine name with a network address (such as an Internet Protocol or “IP” address that is well known the art of modern data and telecommunications networks). These files were locally maintained at each computer on the network.
The development, growth and popularity of the Internet provided for further exploitation of its uses and capabilities which include Voice over Internet Protocol (VoIP). VoIP is a technological development in the field of telecommunications that is utilized to transmit voice conversations over a data network (such as the Internet) using the Internet Protocol (IP). Powerful computers (servers) perform various operations at the Caller, Callee and intermediate points in the network in order to establish the voice conversations. In view of the size and complexity of the Internet, Domain name servers (DNS)'s were created to perform the look-up and retrieval processes that the earlier networked computers were tasked. With DNS, there is no need for applications or the local computers running such applications to store any addressing data (such as the actual machine-readable IP address (e.g., 70.42.251.42) by which machines all over the network use to refer to one another based on the human-readable domain name (e.g., www.howstuffworks.com)).
However, use of DNS also means that additional time in the form of a request for the look-up information, retrieval of such information and the attendant transport delays in the network is spent every time a DNS operation must be performed. Additionally, DNS servers systems must include duplicate machines to meet the robustness and redundancy that is expected from such systems which increases operational and maintenance costs. Regardless of the number of duplicate machines, DNS's are commonly and increasingly targets of attacks to either illegally obtain access to user information of deny users access to domains (websites) that may be served by the attacked DNS. Therefore, it is desirable to provide a means for information retrieval that does not require the use of DNS in order to simplify requests, reduce operating costs and improve reliability in a networked environment.
The disadvantages associated with the prior art are overcome by a method and system for fulfilling information requests in a networked environment. The method includes the steps of receiving a request from a location in the network where the request contains at least an identifier associated with the request; calculating an index value to one or more array locations based on the identifier and retrieving the information from the one or more array locations associated with the index value. The calculating step calculates a value selected from the group consisting of index value to one or more array locations based on the identifier, a value to alter a base IP address and a value for offsetting a previously known or fixed value. The request is selected from the group consisting of a request for information over a distributed database network, a request for a location to consolidate and manage information collected during a communication session attempt and a request for servicing communication sessions and customer features of a communication service. The identifier is selected from the group consisting of a customer identification or account number, a communication session identifier and a communication service customer telephone number. The calculation of the index value is performed by a modulus operation.
This new invention, unlike the old physical addressing methods, does use “names” in a sense to “compute” physical addresses. The “names” could be names or account numbers (i.e., identifiers). There is no local storage or local maintenance of “networking” files. The applications do a “lookup” (server query) at startup to dynamically populate one or more address arrays and/or base IP addresses. Different applications on the same machine may make queries for a different set of addresses. Various “function based” network address configurations can be stored in a central database server that applications query at startup. If network configuration changes occur, the central server can “push” the updates to active applications or just notify them so the applications can “decide” when to get their updates.
So that the manner in which the above recited features of the present invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings.
It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.
To achieve the desired objectives, the subject invention provides for a method of and apparatus for information retrieval from a storage location such as a database without relying on the functionality of a DNS or other similar remote network element. If a server (e.g., proxy server, database server, etc.) receives a request for some type of service (e.g., a database service, a phone call request, a customer feature request, etc.) and is provided an identifier, a modulus operation is applied to the identifier to calculate an index into one or more in-memory server and/or service location arrays. These arrays may contain server/service location addresses and/or location names and/or customer feature sets. Feature sets identify features, feature parameters and/or where to route requests for applying the features. The arrays can contain additional identifiers for calculating indices to other location or feature arrays. The address or name extracted from a location array is used for routing server/service requests. The same operation can be applied by the next and any subsequent server until it reaches a server that can service the request.
Additionally, the apparatus that accomplishes this service request is, in a preferred embodiment of the invention, one or more components of a VoIP communication system. Such communication system is, by way of example, part of any public or private data network (or combination thereof) constructed for (in part) and adapted to convert analog voice signals (e.g., generated by a human utterance) to a digitized and packetized format according to known and understood protocols (such as but not limited to Transmission Control Protocol/Internet Protocol (TCP/IP)) for transmission from an originating point (Party A) to one or more terminating points (Party B and/or C, D and the like). In a preferred embodiment of the invention, the data network is an IP-based network such as (but not limited to) the Internet having VoIP specific and related components connected thereto as explained in greater detail below. Alternately, the telephone call from Party A may originate from a POTS device, linked to the PSTN and eventually linked to VoIP equipment and network(s) to reach Party B.
Three examples are presented to demonstrate this novel modulus approach for name address translation. The first example shows how it can be used within a distributed database network. It also demonstrates how a customer database can be easily scaled and distributed on different servers as the customer base grows. The second example shows how it can be used for consolidating network information such as call information messages (e.g., SIP messages) produced by multiple clients (e.g., proxies) for a particular call to a specific server for generating call detail records (CDR) for the call in a VoIP service provider environment. The third example shows how it can be used for a highly scalable network of proxy servers used for servicing phone calls and customer features in a VoIP service provider environment.
Using Location Arrays for Name Address Translation
When the customer service application is started, the application reads the configuration file and/or accesses the configuration database 116 to initialize internal parameters and/or structures. During initialization, it loads first 118 and second 120 database server location arrays with the addresses of the first 102 and second 104 database processors respectively. The addresses are in ascending order of the modulus operation value of the customer account numbers contained in each database. In other words, the address of first database processor 102 would be first because its database customer account numbers yield a modulus operation value of 0 and those of the second database processor 104 yield a value of 1.
A Database Query Example
When customer support personnel enter a request for customer information based on a customer account number, the request is sent to the Customer Support Application Server 114 for processing. When the customer service application receives the request, it constructs a database query. It determines the database server address where the query is to be sent by calling a name address translation operation. The translation operation uses the numeric customer account number and the number of elements (2) in the database location array to select a database server address. It does this by performing a modulus 2 operation on the account number. For this case, either a 0 or a 1 is returned depending on the value of the account number. The resultant number is used as an index into the array to select the database where the query is to be sent. The operation is as follows:
Numeric_Identifier % Number_of_Array_Elements=Array_Index_Value
IP_Address=Address_Array[Array_Index_Value]
The database server addresses in each of the two arrays 118 and 120 are usually the same but differ when customer records are being relocated due to database expansion. For this example, the database environment is fixed and the two application server location arrays contain the same address elements. When the arrays are equal, only the first array is used by the application for name address translations.
Using Address Masks or Base Addresses for Name Address Translation
As an alternative to using location arrays for information retrieval or name address translation, a common network identifier can be used. For the purposes of the subject invention, the common network identifier can be selected from the group consisting of address masks and base addresses of the first 102 and second 104 database processors. For this alternative, instead of loading two address arrays 118/120 when the customer service application is started, first 122 and second 124 address masks or base addresses are loaded in addition to the number of servers associated with each of the first 122 and second 124 address masks or base addresses. As with the location arrays 118/120, when the address masks or base addresses, and the configuration counts are the same (e.g., the database configurations are not undergoing a change), only the first set is used for information retrieval/name address translations. For that case, only the first server configuration count is used with a customer identifier in the modulus operation to calculate a complimentary database server address value for the given customer. That value is applied to the first address mask or base address 122 for determining where to route the database request. The value is calculated as follows:
Numeric_Customer_Identifier % Number_of_DB_Servers=Address_Modifier_Value
If the configuration counts differ, the database configuration is in a change state and the modulus operation may have to be applied twice. For the first application, the original database configuration count (e.g., two database servers as in
2000477% 2=1
This value is used to change the first base address 122. Either the base network or host portion of the address can be changed. For this example, the network value is changed by adding 1 to the base network value (10.114.138). The request is then sent to the server at address 10.114.139.141 (i.e. the second database processor 104). Similarly, the modulus operation can be applied to computing elements such as but not limited to memory or storage addresses or machine instructions to calculate an offset value of a previously established known or fixed value (i.e., memory address) in order to reallocate information or addressing requirements.
Scalability
As discussed above with respect to the
2000477% 3=2
The database request is then sent to the database server at 10.114.140.141 (i.e., the third database server 202). For the remainder of this example, location arrays are used.
Handling Name Address Translations During Database Growth Transitions
Since customer accounts can not be simultaneously redistributed during database growth transitions, database applications such as the one on the Customer Support Application Server 114, must be able to handle the situation. The use of two database server location arrays previously described make this possible. When the database transition is started, the database server location arrays of all servers are updated. For each server, the first database server location array 118 will contain the addresses of the old database server configuration (
When a customer database server application receives a customer data request and after it constructs a database query, it must determine the address of the database server that is to receive the query. It determines the database server address by calling the name address translation operation. Since for this case, the two database location arrays 118 and 120 differ, the operation is instructed to use the first array 118 for its calculations. The translation operation uses the numeric customer account number and the number of elements in the first array 118 to perform a modulus operation on the account number. The result, as previously described, is then used to select an address from the first array 118. The query is sent to the server with that address. If the query is successful, the results are returned to the user. If the query fails because the account record is not found, the address translation operation is called again and instructed to use the second database server location array 120. This time, for the case shown in
As shown by this last example, databases can be easily scaled as the number of customers grows. Implementation of the modulus methodology does not require any form of a directory name server (i.e., DNS) or a database location service.
Consolidating SIP Messages for Billing Example
The next example demonstrates how information collected from various sources or locations can be organized. In particular, the example is directed to SIP messages generated by multiple proxies at various locations in a VoIP communications network for a particular call can be consolidated for billing by sending them to a specific server for processing. Call information consolidation is often necessary for the generation of call detail records (CDR). Session Initiation Protocol (SIP) is a packed network based communications protocol that is used to establish, tear down and provide additional features and functionality to VoIP telephony. The details and functionality of SIP can be found in the Internet Engineering Task Force (IETF) Request for Comments Paper No. 3261 herein incorporated in its entirety by reference.
The configuration shown in
Numeric_Call_Identifier % Number_of_Array_Elements=Array_Index_Value
Since call identifiers are typically alphanumeric, they must be converted to a numeric value. In a first embodiment of the invention, the conversion is performed by converting each character of a call identifier to its Unicode value. For a call identifier of 3cb059ed-db5cfaf, the Unicode conversion yields a numeric value of 5199984853571011004410098539910297102. Using this call identifier value and a value of 7 (the number elements in the primary location array 316), a location array index value of 3 is calculated as follows:
5199984853571011004410098539910297102% 7=3
For this example, all of the call's SIP messages are sent to the third CDR Generator 3082, the third element in the primary CDR Generator location array. In an alternate embodiment of the invention, a hashing algorithm is applied to the alphanumeric call identifiers to perform the conversion. If such embodiment is to be used, it must always precede any modulus operations as described when calculating the index value.
Scalability
As with the database scalability example previously described, CDR Generators 308 can be easily added to computer network 300. When new servers are added, the existing server IP addresses are not changed. After one or more new CDR Generators are added (i.e., eighth CDR Generator 3087), a CDR Generator location array refresh message is broadcast to all Event Processors 312 with the new configuration IP address data and a date/time value. The date/time value is used by the Event Processors 312 for determining which of the 2 location arrays 316/318 to use for obtaining a CDR Generator IP address. When an Event Processor 312 receives the broadcast refresh message, it loads the new configuration data into the secondary location array 318. Then, when the next SIP message 314 is received, the date/time value received in the broadcast message is compared to the date/time value of the ‘Date’ SIP message header tag, which contains the date/time value of when the call originated. The primary location array 316 (the one with the original IP addresses) is used if the date/time of the SIP message is less (earlier) than the date/time value received in the broadcast message. Otherwise, the secondary location array 318 is used. This way, SIP messages for calls in-progress are still sent to the same CDR Generator. The date/time value received in the broadcast message should be greater (later) than the current date/time such that all Event Processors 312 will have updated their secondary location array 318 (e.g., current date/time+30 minutes may be a good value).
During start up, each Event Processor 312 obtains a maximum call duration time (the maximum time a call can last before it is dropped). When an Event Processor 312 receives a broadcast location server refresh message, it adds the date/time value received to the maximum call duration time. It then uses that value as the time when the secondary location array 318 values are copied to the primary array 316 and the primary location array 316 is again solely used for processing ongoing SIP messages 314.
Proxy Server Example
To use the name address translation methodology, a customer's Direct Inbound Dialing (DID) number is assigned to a proxy 310 within a particular cluster 302 based on the resultant value of a modulus operation on the customer's primary physical (vs. virtual) DID phone number as follows:
DID_Number % Number_of_Proxy_Clusters=Assigned_Proxy_Cluster_Number
For example, for the five proxy clusters 302, if a customer's primary number is 17325553142, the customer's DID would be assigned to a proxy within a particular cluster as follows:
17325553142% 5=2
and the DID number would be assigned to a proxy 310 in the second proxy cluster 3022.
If at some point in time the DID number is reassigned to another cluster for load balancing or some other purpose, the cluster number calculated from the DID number (Modulus_Cluster_Value) is subtracted from the reassigned cluster number and is stored as a load factor value (LFV) for the customer's primary DID number. The LFV is calculated as follows:
LFV=Reassigned_Clust_Number−Modulus_Cluster_Value
The load factor value for a customer's primary DID number for a phone adapter is initially 0 (zero). For the example above, if the DID number is reassigned from the second proxy cluster 3022 to the third proxy cluster 3023, the load factor value for the customer's primary DID number is 1. Using the LFV, the modulus operation for cluster number calculations is:
(DID_Number % Number_of_Proxy_Clusters)+LFV=Assigned_Proxy_Cluster_Number
For the previous example, after relocation, the modulus operation yields the following:
(17325553142% 5)+1=3
When a proxy application is started, a configuration file is read to initialize internal parameters Additional data is obtained from various configuration database tables. Such files and tables (collectively 316) preferably being located in the Database Server 304. To use the name address translation methodology, depending on the proxy type, the proxy 310 must load each of two inbound proxy cluster location arrays (such as arrays 316 and 318 as presented in the previous example, but not shown for sake of clarity in
Internally Placed Calls
When an internal call (i.e., within the VoIP telephony network 400 and not outside to the PSTN 408) is placed, the call request is sent from a customer's phone adapter line associated with a DID to a proxy server 310 associated with the customer's DID. That proxy 310 is a member of a proxy cluster 302 as shown in
If the dialed number is that of an internal customer, the internal callee's physical DID number and a load factor value is returned. The proxy 310 then applies the modulus address translation operation to the numbers returned by the query. If the DID number returned by a query is 17325553142 and the load factor value is 1, the modulus address translation operation is applied as follows to the 5 clusters 302 shown in
(17325553142% 5)+1=3
The resultant value of 3 identifies the cluster where the callee is located. The cluster value is used as an index into the inbound proxy cluster location arrays 316/318 to get the addresses of where the call request is to be sent. If the array addresses found are the same, the request is only sent once. If they differ (e.g., the network may be undergoing a change), the request is sent to both addresses. Only the cluster associated with the callee's DID number services the request. Use of the modulus based operation eliminates the need to access a DNS to obtain the address of the callee's proxy. This method differs from other known methods of address translation because the address is determined within an application via a mathematical process.
Incoming PSTN Calls
When a PSTN call is received at a PSTN gateway 406, a SIP call request is sent to the gateway's proxy server 410. The gateway's proxy server 410 handles the call in a similar fashion as that of the internal call previously described. The only difference is that if the callee's DID number is not an internal customer number, the call is cancelled.
Scalability
As with the previous two scalability examples, the VoIP network 400 example is also highly scalable. Migration to new proxy clusters is done in a similar fashion as that of the database example. When a new proxy cluster 3026 is added, customer DID numbers are re-assigned to a cluster based on the cluster number calculated by applying the modulus methodology to each customer's primary physical DID number using a LFV of 0. This can be performed over a period of time by first refreshing the two inbound proxy cluster location arrays 316/318 of all the proxies with the old and new inbound proxy cluster addresses respectively. This array configuration is maintained until all DID numbers are evaluated for reassignment and re-assigned as needed. At that time, both proxy cluster location arrays 316/318 of all the proxies are refreshed with the same new inbound proxy cluster configuration addresses.
An Alternative to Using Location Arrays
In a further embodiment of the invention, instead of using location arrays for storing server or service IP addresses, a pair of cluster count variables and an IP address mask is used as an alternative for determining where requests are sent. To do so, instead of using the modulus operation result as an array index, it can be used with a method that changes the IP address mask or a base address to compute the address where requests are sent as described in the database example.
Applying the Modulus Operation to Subsequent Servers
Subsequent Server Request Handling
When a request arrives at the proxy grouping 502 and it can not be serviced at that level, the inbound proxy 310 forwards the request to one of its two (or more if it had more) proxy sub-clusters 302subx. It does this by applying the modulus operation to the DID number. The modulus used depends on the number of sub-clusters it has. Using the previous
(17325553142% 5)+1=3
When the call request is received by the inbound proxy 310 of cluster 3 and the proxy finds it must send the call to one of its sub-clusters 302subx, it applies the following operation to determine which cluster:
DID_Number % Number_of_Sub-Clusters=Proxy_Sub-Cluster_Number
Based on the operation, it calculates the cluster number as follows:
17325553142% 2=0
For this case, the inbound proxy 312 would forward the request to the first proxy sub-cluster 302sub1 (also referred to as inbound proxy of sub-cluster 0). Sub-clusters may be nested, have multiple levels and/or be another primary cluster. If a sub-cluster can not service the request, the request is forwarded to one of its sub-clusters by applying the modulus operation. The request can be forwarded again and again until the request is serviced or the last nested cluster is reached.
Using the Modulus Operation for Feature Routing
The modulus operation can be used for feature routing by using feature routing arrays. Certain features (e.g., Voice Mail), may require special customer DID number based routing. These are loaded in feature specific routing arrays. Using the DID number and the number of array elements, the modulus operation is applied to obtain an array index value to extract routing addresses from feature routing arrays when a customer places or receives a call. Similar to the proxy cluster examples, a DID number is associated with a particular feature server based on the value obtained when the modulus operation is applied to the DID number and the number of feature servers available. For the purposes of this example, the feature server and feature server array are located in the network in the same manner as the Database Server 304 and associated Database 306 of the example described in
When a customer places a call, the proxy associated with the customer's DID number gets the customer's feature set. If a feature requires the call request be sent to a feature server, the modulus operation is used to obtain a feature routing array index value by using the customer's DID number and the number of elements in the array. That value is used to retrieve the feature server address associated with the customer's DID number in the feature routing array. The call request is then forwarded to the feature server for processing.
For example, when a call is placed, if a customer DID number had a feature that required anyone placing a call from the number's phone adapter to enter an identification code so that the person making the call could be identified or to limit who could use the phone adapter for placing calls, the proxy servicing the adapter would first obtain the feature set from the feature server as described above. If the “Customer Identification Request” feature is set, the proxy would then send the request to a ‘Customer Identification Request’ server before proceeding with the call. For that DID, when a call is placed, the proxy servicing the call would apply the modulus operation to obtain a feature array index value. Using the index value, the proxy would extract the feature server address from the ‘Customer Identification Request’ feature routing array. After the address is extracted, the proxy would send the call request to the feature server associated with the DID number. The feature server would prompt the user for a code and validate whether or not the caller can use the device. If not, the call is canceled. If so, the identification of the caller is noted in the SIP message and the call proceeds.
In a similar fashion, when an inbound proxy server receives a call, the callee's DID number features are obtained and applied. If a particular feature requires the use of a feature server (e.g. Voice Mail), the server's address is extracted from a feature routing array using the modulus operation and the call is handled accordingly. For example, if a callee had set the Do Not Disturb feature, the call would be routed to the feature server address of the ‘Do Not Disturb’ server associated with the DID number. The address is obtained from the ‘Do Not Disturb’ feature routing array by applying the modulus operation to obtain the index value of the address element associated with the DID number. Or, using another example, if the callee's device is busy and the callee's Voice Mail feature is set, using the modulus operation, a Voice Mail feature routing array is accessed to obtain the address of the Voice Mail server associated with the DID number. The call request is then sent to that Voice Mail server to service the call.
Other Modulus Operation Applications
The modulus operation can be applied to a variety of other services. For example, it can be applied to credit validation service servers in a similar manner as it was in the database and proxy server examples. Identifiers such as user accounts and/or phone numbers can be translated to IP routing addresses within an application using routing arrays and/or IP address masks as previously described.
Apparatus for Performing Name Translation
Any one, combination or all of the servers identified in the above Figures and/or discussed herein can function as a controller that may be used to practice the present invention. The details of such a device are depicted in
The memory 604 is coupled to the CPU 602. The memory 606, or computer-readable medium, may be one or more of readily available memory such as random access memory (RAM), read only memory (ROM), floppy disk, hard disk, flash memory or any other form of digital storage, local or remote. The support circuits 606 are coupled to the CPU 602 for supporting the processor in a conventional manner. These circuits include cache, power supplies, clock circuits, input/output circuitry and subsystems, and the like. A software routine 612, when executed by the CPU 602, causes the controller 600 to perform processes of the present invention and is generally stored in the memory 604. The software routine 612 may also be stored and/or executed by a second CPU (not shown) that is remotely located from the hardware being controlled by the CPU 602.
The software routine 612 is executed when a preferred method of name translation is desired. The software routine 612, when executed by the CPU 602, transforms the general purpose computer into a specific purpose computer (controller) 600 that controls the interaction with one or more customer databases of, for example,
While the subject invention has been described in terms of improved computer server architecture and utilization in a networked environment based on user requests, such requests can be from a user or process to perform one or more actions specific to a device other than a network server. In alternate embodiments of the invention, the device may be, but is not limited to, medical equipment, manufacturing process control equipment, telecommunication equipment and any device capable of initiating actions and/or performing specific actions. Many other scenarios not described here are also possible and within the scope of this application where improved device operation is desirable.
With regard to the specific non server embodiments, a calculation operation is performed based upon the identifier in order to determine one or more actions to fulfill the request. Such actions can result in but are not limited to taking measurements, switching data streams, activating other devices, stopping other devices and initiating and/or performing such actions. Preferably, the calculation is performed on the identifier in conjunction with an operand indicative of the number of possible actions. Examples of action include, but are not limited to measuring temperature, measuring light frequency and switching channels (VoIP data paths), execution of various voice/signal quality measurements and other related actions to effect a telecommunications operation.
At step 706, a calculation operation is performed based upon the identifier in order to determine a location to fulfill the request. Such operation can result in identification of a database storing the requested information, a database (or other similar location) to consolidate or otherwise organize information collected from various sources in the network and a location for executing telecommunication services (such as but not limited to a proxy location for call termination and feature accessing based on customer DID number). Many other scenarios not described here are also possible and within the scope of this application where improved network services are desirable. Preferably, the calculation is a modulus operation that is performed on the identifier in conjunction with an operand indicative of the number of network elements that are part of the request fulfillment operation. In other words, if there are two databases or three proxys that may be likely candidates for request fulfillments as described in the examples above, the operand in the modulus operation is 2 and 3 respectively.
At step 708, the request is executed by accessing the location that resulted from the calculation operation. Such execution includes but is not limited to database access for read or write operations, proxy selection and SIP signaling thereto to effect a telecommunications operation and other as necessary where improved network services are desirable. If network architecture is such that there are two or more levels of hierarchy or nesting of network elements that may be part of the operations of the subject invention, the method may be practiced as many times as necessary (i.e., one calculation for each level of hierarchy) to determine an appropriate location to fulfill the request. After step 708, the method 700 ends at step 710.
While foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof.
The application claims the benefit of U.S. Provisional Application No. 60/998,663, filed Oct. 11, 2007.
Number | Date | Country | |
---|---|---|---|
60998663 | Oct 2007 | US |