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 . fig3 is a block diagram of a functional architecture of a communications network , according to an embodiment of the invention . as shown in fig4 , a functional architecture includes source device 102 , load balancer 302 , performance server 304 , sip servers 306 a , 306 b , 306 c , and 306 d , a network 308 , and a destination device 106 . the load balancer 302 is coupled to the source device 102 , the performance server 304 , and each of the sip servers 306 a , 306 b , 306 c , and 306 d . the performance server 405 is also coupled to each of the sip servers 306 a , 306 b , 306 c , and 306 d . further , network 308 is coupled to each of the sip servers 306 a , 306 b , 306 c , and 306 d and the destination device 106 . the load balancer 302 , performance server 304 , sip servers 306 a , 306 b , 306 c , and 306 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 302 and the performance server 304 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 302 , performance server 304 , sip servers 306 a , 306 b , 306 c , and 306 d may each be configured , for example , with a server operating system , examples of which include linux ™ or windows ™ server operating systems . sip servers 306 a , 306 b , 306 c and 306 d may each be configured as sip proxy servers . the load balancer 302 is configured to receive a sip message from source device 102 . informed by the performance server 304 , the load balancer 302 is configured to forward the sip message from the source device 102 to a selected one of the sip servers 306 a , 306 b , 306 c , and 306 d . in turn , the selected sip server establishes a session between the source device 102 and the destination device 106 . variations of the functional architecture illustrated in fig3 are also contemplated . for example , although four sip servers are illustrated in fig3 , 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 306 a , 306 b , 306 c , and 306 d , according to design choice . fig4 is a block diagram of a functional architecture of the sip load balancer in fig3 , according to an embodiment of the invention . as shown therein , an exemplary load balancer 302 includes sip forwarding module 402 , sip routing module 404 , server load computation module 406 , and server performance query module 408 . the sip routing module 404 is coupled to the sip forwarding module 402 and the server load computation module 406 . the server load computation module 406 is coupled to the sip routing module 404 and the server performance query module 408 . the server performance query module 408 is coupled to the server load computation module 406 . in the illustrated embodiment , each of the couplings described above are two - way couplings . the sip forwarding module 402 is configured to receive a sip request from the source device 102 and send an inquiry to the sip routing module 404 to determine a sip server recipient of the sip message . once the sip forwarding module 402 receives the sip server selection from the sip routing module 404 , the sip forwarding module 402 is configured to forward the sip request to the selected sip server ( e . g ., one of sip servers 306 a , 306 b , 306 c , and 306 d ). in response to a routing inquiry from the sip forwarding module 402 , the sip routing module 404 is configured to request performance scores from the server load computation module 406 , to select a sip server ( e . g ., one of sip servers 306 a , 306 b , 306 c , and 306 d ) based on the performance scores , and forward the selection to the sip forwarding module 402 . the server load computation module 406 is configured to receive a request for performance scores from the sip routing module 404 , request performance data from the server performance query module 408 , calculate a performance score for each of the sip servers 306 a , 306 b , 306 c , and 306 d based on the performance data , and provide the performance scores to the sip routing module 404 . the server performance query module 408 is configured to receive a request for performance data from the server load computation module 406 , solicit performance data from the performance server 304 , and forward the performance data to the server load computation module 406 . variations to the functional architecture illustrated in fig4 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 fig4 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 406 may provide most recent performance scores to the sip routing module 404 without having to first initiate a request for server performance data from the server performance query module 408 . likewise , in response to a request from the server load computation module 406 , the server performance query module 408 may provide most recent server performance data to the server load computation module 406 prior to sending a request to the performance server 304 . embodiments of processes performed by the functional components of the load balancer 302 are further described with reference to fig5 - 10 below . fig5 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 502 . the process then advances to conditional step 504 to determine whether the received request is a registration request . where the result of conditional step 504 is in the affirmative , the process advances to step 506 to route the sip request to all sip servers . in an alternative embodiment , if the result of conditional step 504 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 504 is in the negative , the process is promoted to step 508 to extract a session signature from the sip request in step 508 . the execution of step 508 may vary according to proprietary sip implementation schemes . then , in conditional step 510 , the process determines whether a sip session exists ( e . g ., based on the session signature ). if it is determined in conditional step 510 that a sip session exists ( e . g ., the sip request is associated with an existing sip session ), then the process advances to step 512 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 510 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 514 and advances to conditional step 516 to determine whether the selected sip server has been found . where the result of conditional step 516 is in the negative , the process advances to step 518 to drop ( e . g ., terminate processing of ) the sip request . where the result of conditional step 516 is in the affirmative , the process advances to step 512 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 514 before being forwarded to the selected sip server in step 512 . the load balancer 302 preferably maintains a list of active sip sessions to execute conditional step 510 described above . variations to the process illustrated in fig5 are contemplated . for example , conditional step 504 and associated step 506 are optional . in addition , conditional step 514 may be considered a portion of selection step 516 . fig6 is a flow diagram of a server selection process , according to an embodiment of the invention . in other words , fig6 is one embodiment of selection step 514 . as shown therein , the process begins in step 602 , then advances to step 604 to generate a random integer x , where 0 & lt ; x ≦ σs k . σs k is the sum of performance scores for all sip servers ( shown graphically on integer axis 702 of fig7 ). next , j is set equal to zero in step 606 , and conditional step 608 tests whether ( s 0 + . . . + s j − 1 )& lt ; x ≦( s 0 + . . . s j ). s 0 , s j − 1 , and s j are the performance scores for servers 0 ( s 0 ), j − 1 , and j , respectively . if the result of conditional step 608 is negative , then the value of j is incremented by 1 in step 610 , and the process returns to conditional step 608 . if the result of conditional step 608 is positive , then the process selects server j in step 612 . accordingly , the server selection process 514 illustrated in fig6 tests one or more servers in steps 606 , 608 , and 610 to associate random integer x with a particular server j . the exemplary process illustrated in fig6 can be further understood with reference to the server selection plot illustrated in fig7 . fig7 is a graphical illustration of a server selection plot , according to an embodiment of the invention . as shown in fig7 , data for each of five servers , s 0 , s 1 , s 2 , s 3 , and s 4 are plotted on integer axis 702 and score axis 704 . the integer axis 702 is divided into n partitions sequentially assigned to servers s 0 , s 1 , s 2 , s 3 , and s 4 . for each server , the size of the partition along integer axis 702 is proportional to the performance score . fig7 further illustrates the position on the integer axis 702 for a random integer x generated in step 604 . 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 608 ( with reference to integer axis 702 ) that ( s 0 + s 1 )& lt ; x ≦( s 0 + s 1 + s 2 ). thus , server s 2 would be selected . the performance score s 3 associated with server s 3 is represented by a single point on the integer axis 702 . note that the selection criteria in conditional step 608 prevents selection of a server having a performance score of zero . for example , if random integer x were equal to s 0 + s 1 + s 2 , the point where it is indicated in fig7 that the performance score for server s 3 is equal to zero , server s 2 would be selected by the process depicted in fig6 . as described above , calculation of a performance score for each of the sip servers is a prerequisite to selecting a sip server in step 514 . fig8 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 802 , then advances to step 804 to read each of several parameters . for example , in step 804 , the process reads c i , which is the computer processing unit ( cpu ) usage , expressed as a percentage , for the i th sip server . the process also reads c max , which is the maximum cpu usage , also expressed as a percentage . also in step 804 , the process may read m i , which is the amount of available memory of the i th sip server , expressed as a percentage of total memory . further , in step 804 , 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 804 , the process may read w 0 and w 1 , 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 max is 95 %, m min is 10 mbytes , and w 0 and w 1 are both set equal to 1 . after reading the parameters in step 804 , the process advances to conditional step 806 where it is determined whether c i is less than or equal to c max . where the result of conditional step 806 is in the affirmative , the process advances to step 810 to determine whether m i is greater or equal to m min . where the result of either conditional step 806 or conditional step 810 are in the negative , the process terminates in step 808 , where a performance score s i is set equal to zero . where the result of conditional step 810 is in the affirmative , the process advances to step 812 to calculate the performance score s i given by : s i = 100 ( w 0 ( 1 − c i )+ w i m i / σm k )/ w 0 + w 1 ). advantageously , scoring sensitivity can be adjusted by varying the predetermined weights w 0 and w 1 according to application requirements . fig9 is a graphical illustration of server performance scores 902 , 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 0 and w 1 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 0 and / or w 1 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 . fig1 is a flow diagram of a server performance query process , according to an embodiment of the invention . as shown in fig1 , the process begins in step 1002 , and then advances to step 1004 to set a parameter n equal to 1 . next , the process advances to step 1006 to poll a server psn ( the nth sip server ). then , the process advances to conditional step 1008 to determine whether the data being polled in step 1006 has been received . where the result of conditional step 1008 is in the affirmative , the process advances to step 1012 to determine whether the query process of fig1 is completed . if the result of conditional step 1012 is in the affirmative , the process terminates in step 1016 . where the result of conditional step 1008 is in the negative , the process associates psn with a down condition , and the process continues at conditional step 1012 . where the result of conditional step 1012 is in the negative , the process advances to step 1014 where the server number is incremented by a 1 and the process returns to polling step 1006 . accordingly , the process illustrated in fig1 can be executed by the server performance query module 408 to collect server performance data for each of n sip servers . fig1 - 13 illustrate one embodiment for retrieving the performance data being polled in step 1006 . fig1 is a block diagram of a functional architecture for collecting performance data , according to an embodiment of the invention . as shown in fig1 , performance server 304 is coupled to performance agent 1102 in sip server 306 a and to performance agent 1104 in sip server 306 b . fig1 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 fig1 , the process begins in step 1202 where performance server 304 receives a sip request from load balancer 302 for a specific sip server ( e . g ., sip server 306 a or sip server 306 b ) or other node . next , the process advances to step 1204 where the performance server 304 creates a persistent performance client ( ppc ) for the specified node . next , the process advances to step 1206 where the ppc opens a connection to an agent ( e . g ., performance agent 1102 or performance agent 1104 ) running on the specified node . then , in step 1208 , the ppc issues a “ get data ” request to the agent . next , in step 1210 , the ppc receives and processes a reply from the agent . then , in step 1212 , the performance server 304 sends a performance statistics to the load balancer 302 . finally , in step 1214 the performance server 304 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 . fig1 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 fig1 , upon receipt of an initiation in step 1302 , the process launches three separate and distinct processes : a create collection controller step 1304 , a create server socket step 1312 , and a create notification controller step 1322 . in response to the create collection controller step 1304 , the process advances to gather performance data in step 1306 , then cache performance data in 1308 . after step 1308 , the process may advance to a delay step 1310 before returning to step 1306 to gather additional performance data . subsequent to creating the server socket in step 1312 , the process advances to conditional step 1314 to determine whether a connection request has been received from the performance server 304 . where the result of conditional step 1314 is in the affirmative , the process advances to step 1316 to create a new worker object . next , in step 1318 , the process receives a “ get data ” request from the performance server 304 . then , in step 1320 , the process returns the performance data ( which was gathered in step 1306 and cached in step 1308 ) to the performance server 304 . where the result of conditional step 1314 is in the negative , the process returns to conditional step 1314 . in response to the creation of a notification controller in step 1322 , the process advances to step 1324 to read the performance data cached in step 1308 . next , the process advances to conditional step 1326 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 1326 is in the affirmative , the process issues a notification to the performance server 304 in step 1328 . where the data does not exceed a pre - determined threshold in conditional step 1326 , the process returns to step 1324 to read performance data . variations to the process illustrated in fig1 are contemplated . for example , the implementation of delay step 1310 is optional . in addition , where the result of conditional step 1314 is in the negative , an optional delay step could be inserted before returning to conditional step 1314 . embodiments of the invention described above were tested using the architecture illustrated in fig1 . the test produced the results summarized in fig1 . fig1 is a block diagram of a test bed functional architecture , according to an embodiment of the invention . as shown , sip telephones 1402 and 1404 , softphones 1406 and 1408 , load balancer 1412 , and sip proxy servers 1414 and 1416 were coupled via link 1410 . sip telephones 1402 and 1404 were 3com ® sip telephones , and softphones 1406 and 1408 were implemented with microsoft windows ® messenger running on laptop personal computers . to initialize the test , sip telephones 1402 and 1404 , and softphones 1406 and 1408 were each registered with sip proxy servers 1414 and 1416 . server 1414 was assigned address 10 . 10 . 1 . 213 , and server 1416 was assigned address 10 . 10 . 1 . 208 . in addition , phones 1402 , 1404 , 1406 , and 1408 were each configured with load balancer 1412 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 1414 and 1416 , while signaling messages were generated using phones 1402 , 1404 , 1406 , and 1408 . log messages in load balancer 1412 were later reviewed to determine the number of times that each sip proxy server 1414 and 1416 were selected . fig1 is an illustration of a test results table , according to an embodiment of the invention . as shown therein , the test included four scenarios , 1 - 4 . in scenario 1 , server 1414 and server 1416 were lightly loaded ; the result was that the performance scores were similar , and load balancer 1412 selected servers 1414 and 1416 more or less equally . in scenario 2 , server 1414 was heavily loaded , and server 1416 was lightly loaded ; the result was that server 1416 was selected 17 out of 20 times . in scenario 3 , server 1414 was lightly loaded , and server 1416 was heavily loaded ; the result was that server 1414 was selected 15 out of 20 times . in scenario 4 , server 1414 and server 1416 were both heavily loaded ; the result was that servers 1414 and 1416 were selected more or less equally . 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 .