the embodiments set forth below represent the necessary information to enable those skilled in the art to practice the invention and illustrate the best mode of practicing the invention . upon reading the following description in light of the accompanying drawing figures , those skilled in the art will understand the concepts of the invention and will recognize applications of these concepts not particularly addressed herein . it should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims . before discussing how the present invention works , an explanation of the network environment is presented so as to help understand the context of the present invention . a network 10 may be the public internet ( shown ), a private intranet , or other network through which various elements may interact , such as through any appropriate packet based protocol . a client 12 may be communicatively coupled to the network 10 . the client 12 may be a personal computer , a multimedia enabled phone , or other multimedia enabled customer premises equipment . one or more points of presence ( pops ) 14 , 16 may be associated with one or more service providers . the pops 14 , 16 may have one or more media proxies ( mps ) 18 a , 18 b , and 18 c ( hereinafter , generically a media proxy 18 ) associated therewith , as well as a proximity server 20 , which in a preferred embodiment is a database server . in most installations , it is expected that a single application server 22 may control more than one media proxy 18 , and further the application server 22 may control media proxies 18 distributed amongst multiple pops 14 , 16 . the application server 22 may , in an exemplary embodiment , use session initiation protocol ( sip ) for communicating . for the sake of providing a more complete explanation , a brief digression into the specifics of sip is herein provided . a sip endpoint is generally capable of running an application , which is generally referred to as a user agent ( ua ), and is capable of facilitating media sessions using sip . user agents register their ability to establish sessions with a sip proxy ( the application server 22 in the present invention ) by sending “ register ” messages to the sip proxy . the register message informs the sip proxy of one or more sip universal resource locators ( url ) that identify the user agent to the sip network . the register message also contains information about how to reach specific user agents over the sip network by providing the internet protocol ( ip ) address and port that the user agent will use for sip sessions . a “ subscribe ” message may be used to subscribe to an application or service provided by a sip endpoint . further , “ notify ” messages may be used to provide information between sip endpoints in response to various actions or messages , including register and subscribe messages . when a user agent wants to establish a session with another user agent , the user agent initiating the session will send an invite message to the sip proxy and specify the targeted user agent in the “ to :” header of the invite message . identification of the user agent takes the form of a sip url . in its simplest form , the url is represented by a number or “& lt ; username & gt ;@& lt ; domain & gt ;,” such as “ janedoe @ nortelnetworks . com .” generally , the user name is unique within the name space of the specified domain . if the targeted user agent has registered with the sip proxy , the sip proxy will forward any received invite message directly to the targeted user agent . the targeted user agent will respond with a 200 ok message , and a session between the respective user agents will be established as per the message exchange required in the sip specification . media capabilities are passed between the two user agents of the respective endpoints as parameters embedded within the session setup messages , such as the invite , 200 ok , and acknowledgement ( ack ) messages . the media capabilities are typically described using the session description protocol ( sdp ). once respective endpoints are in an active session with each other and have determined each other &# 39 ; s capabilities , the specified media content may be exchanged during an appropriate media session . returning now to the present invention , the proximity server 20 has a pre - configured list of media proxies 18 , and more specifically , a list of addresses and ports on the media proxies 18 that serve the domains served by the application server 22 . further , at least one port on each media proxy 18 is reserved for running the proximity detection method of the present invention . note that , in general , the client 12 , the media proxy 18 , the proximity server 20 , and the application server 22 all may contain data processing devices , such as a microprocessor . further , the microprocessor may be controlled by software or hardware that performs the functions of the present invention . the software may be stored on any appropriate computer readable medium such as a hard drive , a disc , or other memory device . note further that it is possible that the proximity server 20 and the application server 22 be collocated or integrated into a single entity , but such is not required . the proximity server is one possible host for the proximity detection algorithm . the algorithm is independent of any platform . the methodology of the present invention will now be presented with reference to fig2 and 3 . fig2 is a flowchart of the methodology and fig3 shows the call flows . steps in the flow chart begin with the numeral one , such as block 100 , while steps in the call flow begin with the numeral two , such as message 200 . while particular protocols and messaging examples are provided , they are intended to be exemplary and assist in comprehension of the steps of the present invention . other messaging protocols could be used as needed or desired . in an exemplary embodiment , the proximity server 20 periodically estimates a round trip time ( rtt ) between the proximity server 20 and each of the media proxies 18 under its jurisdiction ( block 100 ). this rtt estimation may be done using an internet control message protocol ( icmp ) ping as is well understood . at some time subsequent to the estimation of the rtt , a client 12 , which may be a sip client , sends a sip register message ( 200 ) requesting registration with the application server 22 ( block 102 ) as part of a request for multimedia services . the application server 22 sends the pre - configured list of addresses ( including port addresses , if appropriate ) to the client 12 for media proxies 18 that are available to serve the domain from which the client &# 39 ; s request originates ( block 104 ). this list of media proxies 18 can be sent in the body of the 200 ok response to the register message ( 202 ). the client 12 sends a simple traversal of udp through network address translators ( stun ), icmp ping , or an application layer probe message ( 204 a , 204 b , 204 c ) to all of the media proxies 18 in the list received from the application server 22 ( block 106 ). this message may include the user identification ( user id ) of the client 12 . the probe may be sent out essentially simultaneously . each media proxy 18 , upon receiving the probe message , sends a notification message ( 206 a , 206 b , 206 c ) reporting the probe event to the proximity server 20 ( block 108 ). this notification message may contain the user identification of the client 12 that triggered the event , as well as a timestamp ( time ). the media proxy 18 also sends back an acknowledgement ( 208 a , 208 b , 208 c ) to the client 12 ( block 110 ) probe . the acknowledgement informs the client 12 which media proxies 18 are reachable . optionally , the media proxy 18 may include in the notification message ( 206 a , 206 b , 206 c ) a timestamp delta representing the time between the receipt of the client probe and the time of sending the notification message to the proximity server 20 . in an exemplary embodiment , the timestamp delta value has a granularity of milliseconds , although finer gradations could be used . the proximity server 20 notes the time of receipt of the notification messages ( block 112 ). the proximity server 20 then uses these values and the round trip time ( rtt ) previously gathered for each of the media proxies 18 to estimate the relative proximities of the client 12 to each of the media proxies 18 ( block 114 ). while there may be several ways to estimate the proximity , an exemplary method to estimate the proximity is as follows . rtt_a , rtt_b , and rtt_c are the rtts for the media proxies 18 a , 18 b , and 18 c , respectively . ta , tb , and tc are the recorded times at the proximity server 20 representing the receipt of the notification messages . the relative proximity values may thus be computed as : note that if the timestamp deltas are present , they may be subtracted out of the calculation for greater accuracy . for example , if a and b are present , then prox ( a , b )=( ta − tb )−( rtt_a − rtt_b )−( a − b ). following the rule that if prox ( a , b )& lt ; 0 ( or negative ), then media proxy 18 a is relatively closer to the client 12 than media proxy 18 b , the following table may be constructed . in the event of the two error cases , the relative proximities cannot be properly determined , and the rtts of the media proxies 18 may be used to represent client 12 proximity . using the rtts is a good approximation so long as the proximity server 20 is located close to the client 12 . note that this proximity detection may , in an exemplary embodiment , only be performed once per registration . armed with the relative proximities , the proximity server 20 may then evaluate other factors ( block 116 ), which include such relatively static factors as : 1 ) the number of hops between the media proxy 18 and the client 12 and 2 ) media proxy 18 capacity . additional dynamic parameters may include the number of user data protocol ( udp ) ports available , the processing power available , the bandwidth available , and statistics relating to jitter , delay , and packet loss at each port . these additional factors may be normalized and weighted as needed or desired to effectuate an appropriate analysis of the suitability of assigning a client 12 to a given media proxy 18 . the proximity server 20 then sends a best fit message ( 210 ) to the application server 22 ( block 118 ). the best fit message ( 210 ) indicates which media proxy 18 is most appropriate for the client 12 to use and is based on the proximity and the additional factors outlined above . the application server 22 then instructs with message 212 the client 12 to use the selected media proxy 18 ( block 120 ). note that the proximity server 20 could provide the instruction to the client 12 . likewise , the processing of the proximity calculations could be performed in the application server 22 , although such is not preferred . appropriate authentication or encryption steps may be taken to prevent duplication of the user identification that may be sent in some of the various messages . likewise , denial of service attacks may be prevented in standard ways , such as monitoring traffic levels . those skilled in the art will recognize improvements and modifications to the preferred embodiments of the present invention . all such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow .