System and method for load balancing a communications network

FIELD OF INVENTION

The invention relates generally to the field of communications. More specifically, but not by way of limitation, the invention relates to a system and method for load balancing a Session Initiation Protocol (SIP) network for applications such as Voice Over Internet Protocol (VoIP) communications and Instant Messaging (IM).

BACKGROUND

Systems and methods are generally known for effecting signaling (control) data on a communications network. <figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram of a functional architecture of a communications network, according to the prior art. As shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, a SIP server <b>104</b> provides communications services such as routing SIP signaling messages between a source device <b>102</b> and a destination device <b>106</b>. Source device <b>102</b> and/or destination device <b>106</b> may be, for example, a SIP-enabled telephone, a SIP PC (Personal Computer) client, a SIP-enabled gateway, or other device configured to originate or terminate a SIP session. <figref idrefs="DRAWINGS">FIG. 2</figref> is a message sequence diagram of communications with a SIP server, according to the prior art. In particular, <figref idrefs="DRAWINGS">FIG. 2</figref> illustrates signaling between the functional blocks in <figref idrefs="DRAWINGS">FIG. 1</figref> using request and response message types: Invite and Bye are request messages; Ringing and OK are response messages.

In typical signaling applications, multiple SIP servers may be used (instead of a single SIP server <b>104</b>) where the communications system also includes multiple sources and/or destination devices. But systems with multiple SIP servers have many disadvantages. For example, known systems may not be able to establish, modify, or terminate at least some SIP sessions where one or more SIP servers have failed. Moreover, requests may be received at SIP servers according to round-robin assignments or theoretical server capacity, resulting in inefficient processing of SIP messages. What is needed is a system and method for performance-based load balancing of SIP servers that can also adapt to one or more failed SIP servers in the system.

SUMMARY OF THE INVENTION

The invention relates to a system and method for load-balancing multiple servers in a communications network. SIP messages are forwarded to one of multiple SIP servers according to a performance score that is calculated from measured performance data from each of the multiple servers.

Embodiments of the invention provide a method for load-balancing a Session Initiation Protocol (SIP) network, including: receiving a SIP request from a source device; selecting one of a plurality of SIP servers based on a plurality of performance scores, each of the plurality of performance scores associated with a corresponding one of the plurality of SIP servers; and forwarding the SIP request to the selected SIP server.

Embodiments of the invention provide a method for polling a SIP server for performance data, including: receiving a data request for the performance data in a performance server; creating a persistent performance client in the performance server; opening a connection to an agent running on the SIP server; and issuing a request from the persistent performance client to the agent.

Embodiments of the invention provide a method responsive to a data request, including: creating a first controller, the first controller being configured to gather and cache performance data; and creating a server socket, the server socket being configured to determine whether a connection request has been received, the server socket being further configured to transmit the performance data.

Embodiments of the invention provide a method for load-balancing a Session Initiation Protocol (SIP) network, including: receiving a SIP request; generating a routing request based on the SIP request; generating a performance score request for each of a plurality of SIP servers based on the routing request; generating a performance data query to each of the plurality of SIP servers based on the performance score request; and receiving the performance data query in an agent in each of the plurality of SIP servers.

Embodiments of the invention provide a communication system, including: an interface to a source device; a load balancer coupled to the interface; a plurality of Session Initiation Server (SIP) servers coupled to the load balancer; and a performance server coupled to the load balancer and the plurality of SIP servers, the performance server configured to collect performance data from the plurality of SIP servers, the load balancer configured to calculate a performance score for each of the plurality of SIP servers based on the performance data, the load balancer further configured to direct a SIP request received from the first interface to a selected one of the plurality of SIP servers based on the performance score for each of the plurality of SIP servers.

Advantageously, the disclosed system and method decreases signaling latency, improving overall communications speed. Moreover, where performance data indicates that a SIP server has failed, the performance score for the failed SIP server is zero, and the load balancer will not forward SIP messages to the failed SIP server. So system uptime is also improved.

The features and advantages of the invention will become apparent from the following drawings and detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are described with reference to the following drawings, wherein:

<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram of a functional architecture of a communications network, according to the prior art;

<figref idrefs="DRAWINGS">FIG. 2</figref> is a message sequence diagram of communications with a SIP server, according to the prior art;

<figref idrefs="DRAWINGS">FIG. 3</figref> is a block diagram of a functional architecture of a communications network, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 4</figref> is a block diagram of a functional architecture of the SIP load balancer in <figref idrefs="DRAWINGS">FIG. 3</figref>, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 5</figref> is a flow diagram of a routing/forwarding process, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 6</figref> is a flow diagram of a server selection process, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 7</figref> is a graphical illustration of a server selection plot, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 8</figref> is a flow diagram of a process for calculating server load, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 9</figref> is a graphical illustration of server load scores, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 10</figref> is a flow diagram of a server performance query process, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 11</figref> is a block diagram of a functional architecture for collecting performance data, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 12</figref> is a flow diagram of a polling process from the perspective of a performance server, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 13</figref> is a flow diagram for a polling process from the perspective of a performance agent on a SIP server, according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 14</figref> is a block diagram of a test bed functional architecture, according to an embodiment of the invention; and

<figref idrefs="DRAWINGS">FIG. 15</figref> is an illustration of a test results table, according to an embodiment of the invention.

DETAILED DESCRIPTION

This section provides a top-level functional architecture, exemplary selection, routing and forwarding processes, a process for calculating a performance score, a process for collecting performance data, and a summary of empirical analysis. Sub-headings are used below for organizational convenience. The disclosure of any particular feature is not necessarily limited to any particular section, however.

Top Level Functional Architecture

<figref idrefs="DRAWINGS">FIG. 3</figref> is a block diagram of a functional architecture of a communications network, according to an embodiment of the invention. As shown in <figref idrefs="DRAWINGS">FIG. 4</figref>, a functional architecture includes source device <b>102</b>, load balancer <b>302</b>, performance server <b>304</b>, SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D, a network <b>308</b>, and a destination device <b>106</b>. The load balancer <b>302</b> is coupled to the source device <b>102</b>, the performance server <b>304</b>, and each of the SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D. The performance server <b>405</b> is also coupled to each of the SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D. Further, network <b>308</b> is coupled to each of the SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D and the destination device <b>106</b>.

The load balancer <b>302</b>, performance server <b>304</b>, SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D may each include a processor, each of the processors being configured to read and execute instructions from a processor-readable storage medium. In one variation, the load balancer <b>302</b> and the performance server <b>304</b> share a processor. The storage medium may be or include, for instance, a hard drive, Random Access Memory (RAM), or a Computer Disc (CD) Read Only memory (ROM). The load balancer <b>302</b>, performance server <b>304</b>, SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D may each be configured, for example, with a server operating system, examples of which include Linux™ or Windows™ server operating systems. SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C and <b>306</b>D may each be configured as SIP proxy servers.

The load balancer <b>302</b> is configured to receive a SIP message from source device <b>102</b>. Informed by the performance server <b>304</b>, the load balancer <b>302</b> is configured to forward the SIP message from the source device <b>102</b> to a selected one of the SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D. In turn, the selected SIP server establishes a session between the source device <b>102</b> and the destination device <b>106</b>.

Variations of the functional architecture illustrated in <figref idrefs="DRAWINGS">FIG. 3</figref> are also contemplated. For example, although four SIP servers are illustrated in <figref idrefs="DRAWINGS">FIG. 3</figref>, a functional architecture may have two or more SIP servers. Further, in a general case, a functional architecture may include multiple source devices and/or multiple destination devices. Moreover, switches or servers configured for H.323 or other IP telephony or other communications protocol could be used in the alternative to, or in combination with, the illustrated SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D, according to design choice.

<figref idrefs="DRAWINGS">FIG. 4</figref> is a block diagram of a functional architecture of the SIP load balancer in <figref idrefs="DRAWINGS">FIG. 3</figref>, according to an embodiment of the invention. As shown therein, an exemplary load balancer <b>302</b> includes SIP forwarding module <b>402</b>, SIP routing module <b>404</b>, server load computation module <b>406</b>, and server performance query module <b>408</b>. The SIP routing module <b>404</b> is coupled to the SIP forwarding module <b>402</b> and the server load computation module <b>406</b>. The server load computation module <b>406</b> is coupled to the SIP routing module <b>404</b> and the server performance query module <b>408</b>. The server performance query module <b>408</b> is coupled to the server load computation module <b>406</b>. In the illustrated embodiment, each of the couplings described above are two-way couplings.

The SIP forwarding module <b>402</b> is configured to receive a SIP request from the source device <b>102</b> and send an inquiry to the SIP routing module <b>404</b> to determine a SIP server recipient of the SIP message. Once the SIP forwarding module <b>402</b> receives the SIP server selection from the SIP routing module <b>404</b>, the SIP forwarding module <b>402</b> is configured to forward the SIP request to the selected SIP server (e.g., one of SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D).

In response to a routing inquiry from the SIP forwarding module <b>402</b>, the SIP routing module <b>404</b> is configured to request performance scores from the server load computation module <b>406</b>, to select a SIP server (e.g., one of SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D) based on the performance scores, and forward the selection to the SIP forwarding module <b>402</b>.

The server load computation module <b>406</b> is configured to receive a request for performance scores from the SIP routing module <b>404</b>, request performance data from the server performance query module <b>408</b>, calculate a performance score for each of the SIP servers <b>306</b>A, <b>306</b>B, <b>306</b>C, and <b>306</b>D based on the performance data, and provide the performance scores to the SIP routing module <b>404</b>.

The server performance query module <b>408</b> is configured to receive a request for performance data from the server load computation module <b>406</b>, solicit performance data from the performance server <b>304</b>, and forward the performance data to the server load computation module <b>406</b>.

Variations to the functional architecture illustrated in <figref idrefs="DRAWINGS">FIG. 4</figref> are possible. For example, any of the functional capability illustrated therein and described above may be combined in functional groupings different from that illustrated in <figref idrefs="DRAWINGS">FIG. 4</figref> and described above.

In operation, data may be cached or otherwise stored at various locations of the functional architecture. For instance, in response to a request for performance scores, server load computation module <b>406</b> may provide most recent performance scores to the SIP routing module <b>404</b> without having to first initiate a request for server performance data from the server performance query module <b>408</b>. Likewise, in response to a request from the server load computation module <b>406</b>, the server performance query module <b>408</b> may provide most recent server performance data to the server load computation module <b>406</b> prior to sending a request to the performance server <b>304</b>.

Embodiments of processes performed by the functional components of the load balancer <b>302</b> are further described with reference to <figref idrefs="DRAWINGS">FIGS. 5-10</figref> below.

Selection, Routing, and Forwarding Processes

<figref idrefs="DRAWINGS">FIG. 5</figref> is a flow diagram of a routing/forwarding process, according to an embodiment of the invention. As shown therein, the process begins by receiving a SIP request in step <b>502</b>. The process then advances to conditional step <b>504</b> to determine whether the received request is a registration request. Where the result of conditional step <b>504</b> is in the affirmative, the process advances to step <b>506</b> to route the SIP request to all SIP servers. In an alternative embodiment, if the result of conditional step <b>504</b> is in the affirmative, the process routes the SIP request to a registrar server (step not shown).

On the other hand, where the result of conditional step <b>504</b> is in the negative, the process is promoted to step <b>508</b> to extract a session signature from the SIP request in step <b>508</b>. The execution of step <b>508</b> may vary according to proprietary SIP implementation schemes. Then, in conditional step <b>510</b>, the process determines whether a SIP session exists (e.g., based on the session signature). If it is determined in conditional step <b>510</b> that a SIP session exists (e.g., the SIP request is associated with an existing SIP session), then the process advances to step <b>512</b> to forward the SIP request to the (pre)selected SIP server associated with the existing SIP session. Accordingly, a SIP request associated with an active session is simply routed to the appropriate SIP server.

If it is determined in conditional step <b>510</b> that a SIP session does not exist (e.g., the request is associated with a new SIP session), then the process selects a SIP server in step <b>514</b> and advances to conditional step <b>516</b> to determine whether the selected SIP server has been found. Where the result of conditional step <b>516</b> is in the negative, the process advances to step <b>518</b> to drop (e.g., terminate processing of) the SIP request. Where the result of conditional step <b>516</b> is in the affirmative, the process advances to step <b>512</b> to forward the SIP request to the (newly) selected SIP server. Accordingly, a SIP request associated with a new session requires selection of a SIP server in step <b>514</b> before being forwarded to the selected SIP server in step <b>512</b>. The load balancer <b>302</b> preferably maintains a list of active SIP sessions to execute conditional step <b>510</b> described above.

Variations to the process illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref> are contemplated. For example, conditional step <b>504</b> and associated step <b>506</b> are optional. In addition, conditional step <b>514</b> may be considered a portion of selection step <b>516</b>.

<figref idrefs="DRAWINGS">FIG. 6</figref> is a flow diagram of a server selection process, according to an embodiment of the invention. In other words, <figref idrefs="DRAWINGS">FIG. 6</figref> is one embodiment of selection step <b>514</b>. As shown therein, the process begins in step <b>602</b>, then advances to step <b>604</b> to generate a random integer X, where 0&lt;X≦ΣS_k. ΣS_kis the sum of performance scores for all SIP servers (shown graphically on integer axis <b>702</b> of <figref idrefs="DRAWINGS">FIG. 7</figref>).

Next, j is set equal to zero in step <b>606</b>, and conditional step <b>608</b> tests whether (S₀+ . . . +S_j−1)&lt;X≦(S₀+ . . . S_j). S₀, S_j−1, and S_jare the performance scores for servers <b>0</b> (S<b>0</b>), j−1, and j, respectively. If the result of conditional step <b>608</b> is negative, then the value of j is incremented by 1 in step <b>610</b>, and the process returns to conditional step <b>608</b>. If the result of conditional step <b>608</b> is positive, then the process selects server j in step <b>612</b>.

Accordingly, the server selection process <b>514</b> illustrated in <figref idrefs="DRAWINGS">FIG. 6</figref> tests one or more servers in steps <b>606</b>, <b>608</b>, and <b>610</b> to associate random integer X with a particular server j. The exemplary process illustrated in <figref idrefs="DRAWINGS">FIG. 6</figref> can be further understood with reference to the server selection plot illustrated in <figref idrefs="DRAWINGS">FIG. 7</figref>.

<figref idrefs="DRAWINGS">FIG. 7</figref> is a graphical illustration of a server selection plot, according to an embodiment of the invention. As shown in <figref idrefs="DRAWINGS">FIG. 7</figref>, data for each of five servers, S<b>0</b>, S<b>1</b>, S<b>2</b>, S<b>3</b>, and S<b>4</b> are plotted on integer axis <b>702</b> and score axis <b>704</b>. The integer axis <b>702</b> is divided into N partitions sequentially assigned to servers S<b>0</b>, S<b>1</b>, S<b>2</b>, S<b>3</b>, and S<b>4</b>. For each server, the size of the partition along integer axis <b>702</b> is proportional to the performance score.

<figref idrefs="DRAWINGS">FIG. 7</figref> further illustrates the position on the integer axis <b>702</b> for a random integer X generated in step <b>604</b>. It should be apparent that the larger the performance score for a server, the larger the partition size, and the more likely that the random integer X will be associated with a server having a relatively larger performance score. It would be determined in step <b>608</b> (with reference to integer axis <b>702</b>) that (S₀+S₁)&lt;X≦(S₀+S₁+S₂). Thus, server S<b>2</b> would be selected.

The performance score S₃associated with server S<b>3</b> is represented by a single point on the integer axis <b>702</b>. Note that the selection criteria in conditional step <b>608</b> prevents selection of a server having a performance score of zero. For example, if random integer X were equal to S₀+S₁+S₂, the point where it is indicated in <figref idrefs="DRAWINGS">FIG. 7</figref> that the performance score for server S<b>3</b> is equal to zero, server S<b>2</b> would be selected by the process depicted in <figref idrefs="DRAWINGS">FIG. 6</figref>.

As described above, calculation of a performance score for each of the SIP servers is a prerequisite to selecting a SIP server in step <b>514</b>.

Calculating a Performance Score

<figref idrefs="DRAWINGS">FIG. 8</figref> is a flow diagram of a process for calculating server load (or performance score), according to an embodiment of the invention. As shown therein, the process begins in step <b>802</b>, then advances to step <b>804</b> to read each of several parameters. For example, in step <b>804</b>, the process reads C_i, which is the Computer Processing Unit (CPU) usage, expressed as a percentage, for the i^thSIP server. The process also reads C_max, which is the maximum CPU usage, also expressed as a percentage. Also in step <b>804</b>, the process may read M_i, which is the amount of available memory of the i^thSIP server, expressed as a percentage of total memory. Further, in step <b>804</b>, the process reads M_min, which is the minimum required memory (again, expressed as a percentage of total memory). The process may also read or calculate ΣM_k, which is the sum of the available memory for all SIP servers with a non-zero performance score. Finally, in step <b>804</b>, the process may read W₀and W₁, which are the predetermined weight of the CPU usage percentage parameter and the predetermined weight of the memory availability parameter, respectively. In one embodiment, C_maxis 95%, M_minis 10 Mbytes, and W₀and W₁are both set equal to 1.

After reading the parameters in step <b>804</b>, the process advances to conditional step <b>806</b> where it is determined whether C_iis less than or equal to C_max. Where the result of conditional step <b>806</b> is in the affirmative, the process advances to step <b>810</b> to determine whether M_iis greater or equal to M_min. Where the result of either conditional step <b>806</b> or conditional step <b>810</b> are in the negative, the process terminates in step <b>808</b>, where a performance score S_iis set equal to zero. Where the result of conditional step <b>810</b> is in the affirmative, the process advances to step <b>812</b> to calculate the performance score S_igiven by: S_i=100(W₀(1−C_i)+W_iM_i/ΣM_k)/W₀+W₁). Advantageously, scoring sensitivity can be adjusted by varying the predetermined weights W₀and W₁according to application requirements.

<figref idrefs="DRAWINGS">FIG. 9</figref> is a graphical illustration of server performance scores <b>902</b>, according to an embodiment of the invention. As shown, the highest performance score, 100%, is the case where CPU usage (C_i) is 0%, and memory availability (M_i) is 100%. As CPU and/or memory resources become less available, the performance score drops. Where the CPU usage (C_i) is 100%, and/or where the memory availability (M_i) is 0%, the performance score is equal to zero. In the illustrated embodiment, W₀and W₁are both set equal to 1. In alternative embodiments, the scoring solution can be made more sensitive to either memory availability or CPU utilization by changing the value of W₀and/or W₁either off-line or in-situ.

In alternative embodiments of the invention, the above calculation may be performed without a CPU usage parameter, or without a memory availability parameter. Moreover, in other embodiments, performance scores may be calculated based on network utilization, call volume, failure statistics (such as indications of server down status, or abnormal SIP session terminations), and/or other factors either separately or combined with CPU usage and/or memory availability so that multiple SIP servers can be load balanced based on one or more performance metrics, and/or so that fault tolerance can be provided to a SIP-based application.

Collecting Performance Data

<figref idrefs="DRAWINGS">FIG. 10</figref> is a flow diagram of a server performance query process, according to an embodiment of the invention. As shown in <figref idrefs="DRAWINGS">FIG. 10</figref>, the process begins in step <b>1002</b>, and then advances to step <b>1004</b> to set a parameter N equal to 1. Next, the process advances to step <b>1006</b> to poll a server PSN (the Nth SIP server). Then, the process advances to conditional step <b>1008</b> to determine whether the data being polled in step <b>1006</b> has been received. Where the result of conditional step <b>1008</b> is in the affirmative, the process advances to step <b>1012</b> to determine whether the query process of <figref idrefs="DRAWINGS">FIG. 10</figref> is completed. If the result of conditional step <b>1012</b> is in the affirmative, the process terminates in step <b>1016</b>.

Where the result of conditional step <b>1008</b> is in the negative, the process associates PSN with a down condition, and the process continues at conditional step <b>1012</b>. Where the result of conditional step <b>1012</b> is in the negative, the process advances to step <b>1014</b> where the server number is incremented by a 1 and the process returns to polling step <b>1006</b>.

Accordingly, the process illustrated in <figref idrefs="DRAWINGS">FIG. 10</figref> can be executed by the server performance query module <b>408</b> to collect server performance data for each of N SIP servers. <figref idrefs="DRAWINGS">FIGS. 11-13</figref> illustrate one embodiment for retrieving the performance data being polled in step <b>1006</b>.

<figref idrefs="DRAWINGS">FIG. 11</figref> is a block diagram of a functional architecture for collecting performance data, according to an embodiment of the invention. As shown in <figref idrefs="DRAWINGS">FIG. 11</figref>, performance server <b>304</b> is coupled to performance agent <b>1102</b> in SIP server <b>306</b>A and to performance agent <b>1104</b> in SIP server <b>306</b>B.

<figref idrefs="DRAWINGS">FIG. 12</figref> is a flow diagram of a polling process from the perspective of a performance server, according to an embodiment of the invention. As shown in <figref idrefs="DRAWINGS">FIG. 12</figref>, the process begins in step <b>1202</b> where performance server <b>304</b> receives a SIP request from load balancer <b>302</b> for a specific SIP server (e.g., SIP server <b>306</b>A or SIP server <b>306</b>B) or other node. Next, the process advances to step <b>1204</b> where the performance server <b>304</b> creates a persistent performance client (PPC) for the specified node. Next, the process advances to step <b>1206</b> where the PPC opens a connection to an agent (e.g., performance agent <b>1102</b> or performance agent <b>1104</b>) running on the specified node. Then, in step <b>1208</b>, the PPC issues a “get data” request to the agent. Next, in step <b>1210</b>, the PPC receives and processes a reply from the agent. Then, in step <b>1212</b>, the performance server <b>304</b> sends a performance statistics to the load balancer <b>302</b>. Finally, in step <b>1214</b> the performance server <b>304</b> caches the PPC.

Thus, in one embodiment of the invention, performance data is collected by one or more performance servers using agents that are embedded in each of the SIP servers.

<figref idrefs="DRAWINGS">FIG. 13</figref> is a flow diagram for a polling process from the perspective of a performance agent on a SIP server, according to an embodiment of the invention. As illustrated in <figref idrefs="DRAWINGS">FIG. 13</figref>, upon receipt of an initiation in step <b>1302</b>, the process launches three separate and distinct processes: a create collection controller step <b>1304</b>, a create server socket step <b>1312</b>, and a create notification controller step <b>1322</b>.

In response to the create collection controller step <b>1304</b>, the process advances to gather performance data in step <b>1306</b>, then cache performance data in <b>1308</b>. After step <b>1308</b>, the process may advance to a delay step <b>1310</b> before returning to step <b>1306</b> to gather additional performance data.

Subsequent to creating the server socket in step <b>1312</b>, the process advances to conditional step <b>1314</b> to determine whether a connection request has been received from the performance server <b>304</b>. Where the result of conditional step <b>1314</b> is in the affirmative, the process advances to step <b>1316</b> to create a new worker object. Next, in step <b>1318</b>, the process receives a “get data” request from the performance server <b>304</b>. Then, in step <b>1320</b>, the process returns the performance data (which was gathered in step <b>1306</b> and cached in step <b>1308</b>) to the performance server <b>304</b>. Where the result of conditional step <b>1314</b> is in the negative, the process returns to conditional step <b>1314</b>.

In response to the creation of a notification controller in step <b>1322</b>, the process advances to step <b>1324</b> to read the performance data cached in step <b>1308</b>. Next, the process advances to conditional step <b>1326</b> to determine whether the performance data exceeds a predetermined threshold. For example, a CPU utilization threshold may be set at 85%, and a memory availability threshold may be set at 10 MB. Where the result of step <b>1326</b> is in the affirmative, the process issues a notification to the performance server <b>304</b> in step <b>1328</b>. Where the data does not exceed a pre-determined threshold in conditional step <b>1326</b>, the process returns to step <b>1324</b> to read performance data.

Variations to the process illustrated in <figref idrefs="DRAWINGS">FIG. 13</figref> are contemplated. For example, the implementation of delay step <b>1310</b> is optional. In addition, where the result of conditional step <b>1314</b> is in the negative, an optional delay step could be inserted before returning to conditional step <b>1314</b>.

Empirical Analysis

Embodiments of the invention described above were tested using the architecture illustrated in <figref idrefs="DRAWINGS">FIG. 14</figref>. The test produced the results summarized in <figref idrefs="DRAWINGS">FIG. 15</figref>.

<figref idrefs="DRAWINGS">FIG. 14</figref> is a block diagram of a test bed functional architecture, according to an embodiment of the invention. As shown, SIP telephones <b>1402</b> and <b>1404</b>, softphones <b>1406</b> and <b>1408</b>, Load balancer <b>1412</b>, and SIP proxy servers <b>1414</b> and <b>1416</b> were coupled via link <b>1410</b>. SIP telephones <b>1402</b> and <b>1404</b> were 3Com® SIP telephones, and softphones <b>1406</b> and <b>1408</b> were implemented with Microsoft Windows® Messenger running on laptop personal computers.

To initialize the test, SIP telephones <b>1402</b> and <b>1404</b>, and softphones <b>1406</b> and <b>1408</b> were each registered with SIP proxy servers <b>1414</b> and <b>1416</b>. Server <b>1414</b> was assigned address 10.10.1.213, and server <b>1416</b> was assigned address 10.10.1.208. In addition, phones <b>1402</b>, <b>1404</b>, <b>1406</b>, and <b>1408</b> were each configured with load balancer <b>1412</b> address 10.10.1.221 as the outbound proxy address. A software tool was used to generate a controlled load on each of the SIP proxy servers <b>1414</b> and <b>1416</b>, while signaling messages were generated using phones <b>1402</b>, <b>1404</b>, <b>1406</b>, and <b>1408</b>. Log messages in load balancer <b>1412</b> were later reviewed to determine the number of times that each SIP proxy server <b>1414</b> and <b>1416</b> were selected.

<figref idrefs="DRAWINGS">FIG. 15</figref> is an illustration of a test results table, according to an embodiment of the invention. As shown therein, the test included four scenarios, <b>1</b>-<b>4</b>.

In scenario <b>1</b>, server <b>1414</b> and server <b>1416</b> were lightly loaded; the result was that the performance scores were similar, and load balancer <b>1412</b> selected servers <b>1414</b> and <b>1416</b> more or less equally. In scenario <b>2</b>, server <b>1414</b> was heavily loaded, and server <b>1416</b> was lightly loaded; the result was that server <b>1416</b> was selected 17 out of 20 times. In scenario <b>3</b>, server <b>1414</b> was lightly loaded, and server <b>1416</b> was heavily loaded; the result was that server <b>1414</b> was selected 15 out of 20 times. In scenario <b>4</b>, server <b>1414</b> and server <b>1416</b> were both heavily loaded; the result was that servers <b>1414</b> and <b>1416</b> were selected more or less equally.

CONCLUSION

The invention described above thus overcomes the disadvantages of known systems and methods by balancing signaling load amongst multiple servers based on performance scores calculated from measured performance data. While this invention has been described in various explanatory embodiments, other embodiments and variations can be effected by a person of ordinary skill in the art without departing from the scope of the invention. For example, the systems and methods described herein could be applied to different signaling protocols or communication environments.